Show file download/upload/print affordances in app context

[rtibblesbot]

Summary

• isAppContext gates hid file upload/download/print affordances in installed apps — a workaround from when apps couldn't handle downloads. Removes the four gates so the affordances render in every context.
• Affordances: content "Save to device", coach CSV export, facility CSV import/export + log downloads, "Print all passwords".

Once visible in-app, several of them didn't actually work. Fixed here:

• Facility CSV downloads did nothing. window.open(url, '_blank') is a no-op in the webview. New DataPage/downloadCsvFile.js clicks a synthetic <a download> instead — the same idiom the coach export already used via csv-generator-client.
• The CSV import picker greyed out every file on Android. onShowFileChooser passed the web accept entries straight into OpenDocument, which filters on EXTRA_MIME_TYPES — a bare .csv is not a MIME type and matches nothing. New FileChooserUtils.toPickerMimeTypes resolves extensions through MimeTypeMap, the same map document providers type files with. The input lists accept="text/csv,.csv" so providers that report a type rather than derive one also match.
• The Mac/Linux app saved nothing. The WebKit backends wxPython's html2 uses ignore an anchor's download: an http(s) link navigated the webview to the CSV in place of the page, and the data: URLs the coach exporter builds were dropped entirely. An injected script now intercepts a[download] clicks, reads the resource in the page where the session cookie lives, and hands the bytes to Python to write out through a save dialog. WebView2 has its own download UI, so Windows keeps only the print shim it had. Bridge messages are JSON keyed on type now that there is more than one.
• Android downloads looked stuck. The download leaves the page as soon as the button is pressed and finishes in the notification shade, so the page shows nothing. Toast on start, completion and failure.

References

Fixes #14654. Android WebView download support: learningequality/kolibri-installer-android#267.

Reviewer guidance

Confirm each of:

• Printing
• File upload (e.g. user import)
• File download (e.g. log file download)

On each of:

• Android app
• Mac App
• Windows App

AI usage

Used Claude Code to remove the gates and update tests following a pre-approved plan. Verified with the affected Jest, pytest and JVM suites and prek lint. The four platform fixes came out of manual QA in the Windows, Mac and Android apps.

Deviations from the issue spec

• Adds the four platform fixes above, which the issue's change list doesn't mention. Removing the gates alone would have shipped a visible-but-broken CSV download, import picker and Mac/Linux save path in the apps.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Ran pre-flight CI checks (lint, format, tests) and verified all pass
• Rebased onto the target branch and resolved any conflicts
• Reorganized commit history into clean, logical commits
• Audited the diff to ensure only issue-relevant files are changed
• Built PR body from the repository's PR template with evidence blocks

🟡 Waiting for feedback Last updated: 2026-07-29 17:12 UTC

[github-actions]

npm Package Versions

Warning

The following packages have changed files but no version bump:

Package	Version	Changed files
kolibri	0.18.0	2

If these changes affect published code, consider bumping the version.

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.19.6.dev2364_g4a077af96.d20260729.pex
Windows Installer (EXE)	kolibri-setup-0.19.6.dev2364+g4a077af96.d20260729-unsigned.exe
Debian Package	kolibri_0.19.6.dev2364+g4a077af96-0ubuntu1_all.deb
Debian Package	kolibri-server_0.19.6~dev2364+g4a077af96.d20260729-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.19.6.dev2364+g4a077af96.d20260729.dmg
Android Package (APK)	kolibri-0.19.6.dev2364+g4a077af96-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.19.6.dev2364+g4a077af96.zip
TAR file	kolibri-0.19.6.dev2364+g4a077af96.d20260729.tar.gz
WHL file	kolibri-0.19.6.dev2364+g4a077af96.d20260729-py3-none-any.whl

Smoke test screenshot

Download screenshot

[rtibbles]

A little bit more cleanup, but the code here looks broadly sensible.

[rtibbles]

Just one more bit of cleanup, then please tidy up the commit history.

[rtibbles]

Code makes sense - needs commit history tidy up, ready for manual QA though.

[rtibblesbot]

Tidied the commit history — squashed the four per-component commits into a single commit (Show file upload/download/print affordances in app context) since this is one cohesive change removing the isAppContext gates. The tree is byte-identical to the previous head; only the history changed. Ready for manual QA.

[radinamatic]

EXE installed on Windows 11:

• Printing lesson and coach reports, as well as the passwords working correctly ✔️

  

• File upload (CSV with users) import also working as expected ✔️

• File download: CSV file download for quizzes and lessons reports is successful ✔️, however, summary and session logs, as well as the generated new user CSV file, cannot be downloaded from the app UI, although all features work when Kolibri is opened in the browser.

kolibri-app.zip

[radinamatic]

APK installed on Redmi10C with Android 13:

All printing/saving as PDF, plus saving/downloading CSV files is working beautifully, even those on the Facility/Data page that are failing in Windows app! 🎉 🎆

And I even had the Android Studio ready and connected to the device to capture any potential issues... 😅

Just need to restart and try the CSV file import feature, but looking great for now 👏🏽

[radinamatic]

Not able to import a CSV file to Kolibri installed on Android: the button Choose file responds correctly, opens the device file manager, but the corresponding CSV file seems grayed out and nothing happens when it's tapped 🤔

It happens for both the CSV files copied directly to the device's internal storage (so technically no downloading would be required), and the CSV file uploaded to a Google Drive (I can see the CSV file to select, but nothing happens when I tried to tap it to import).

Tried setting up both as OnMyOwn and GroupLearning, just in case something would be different in the logcats.

logs.zip

[rtibblesbot]

Thanks — both traced to a concrete cause and are fixed in 1ba7521 and 6c19c40. Needs a fresh build to re-verify on device.

Windows downloads. Session logs, summary logs and the generated user CSV were the only three call sites using window.open(url, '_blank'); the app webview opens no new window, so nothing happened. The exports that worked for you click an <a download> instead — all three now use that same mechanism.

Android CSV import. accept=".csv" is a browser-only shorthand. The webview passes the first accept entry to the system file picker as a MIME type, and nothing matches the literal string .csv, so every file greys out. Now accept="text/csv,.csv".

If Android still greys out CSVs after this build, the chooser intent is built shell-side and belongs to kolibri-installer-android#267.

[radinamatic]

Fix on Windows is confirmed, downloading CSV files is now working for all the features on Facility - Data page.

[radinamatic]

Still hitting some bumps with importing CSV in Kolibri on Android:

• CSV files located on the device are still grayed out, could it be a permission issue?
• CSV on the GDrive was not grayed out and it was possible to select. However, once I pressed the Continue button, server seems to disconnect and it was not possible to proceed.

logs.zip
logcat from Android Studio are included.

[rtibblesbot]

Thanks — the logcat had both answers in it. One is fixed here in de97ef7; the other is a separate bug I've filed as #15094.

Greyed-out local CSVs — fixed. I had this wrong when I said it was the accept attribute. WebViewActivity.onShowFileChooser passed the accept entries straight into OpenDocument, which filters on EXTRA_MIME_TYPES:

String[] mimeTypes = Arrays.stream(accepted != null ? accepted : new String[0])
    .filter(t -> t != null && !t.isEmpty())
    .toArray(String[]::new);

.csv is not a MIME type, so it matched nothing; text/csv was doing all the filtering. That is exactly the split you saw — Drive reports text/csv and stayed selectable, while local files get their type from MimeTypeMap, which maps .csv to something else. The picker now resolves extensions through that same MimeTypeMap, so a local file and the filter always agree. Covered by FileChooserUtilsTest.

Server disconnect on Continue — not this PR. Opening the picker backgrounds the activity, and after ~60s Android stops the server:

00:34:43.896 ActivityManager W Stopping service due to app idle: u0a1 -3m16s676ms
                                org.learningequality.Kolibri/.KolibriServerService

It then comes back on a different port (46655 → 45791) and the shell reloads the WebView, which discards the picked file. So the file selection was fine; the page underneath it was replaced. That's a service-lifecycle problem affecting any handoff to another activity, not just CSV import, so I've filed #15094 rather than widen this PR.

That means CSV import on Android still won't complete until #15094 lands — worth knowing before you re-test. What this build should show is that local CSVs are selectable rather than greyed. If you pick one quickly enough to stay inside the idle window, the import should go through.

Needs a fresh build.

[rtibblesbot]

One follow-up on that: the new FileChooserUtilsTest would not have run in CI. tox.yml's path filter is ["**.py", ".github/workflows/tox.yml", "pyproject.toml", "uv.lock", "python_packages/**"], so a Java-only change under platforms/ skips every job gated on it — including the Android JVM tests added in #15075, which exist to cover exactly that code. Added platforms/** in ee55fb7.

Shout if you'd rather that went in its own PR.

[pcenov]

Mac app:

1. Going to Facility > Data and clicking any of the available file download buttons results in directly opening the .csv file inside the Mac app instead of actually downloading the file to the device.
2. The Export as CSV button is not working it all of the Coach pages - nothing happens when I click it.

Here's a video for both issues:

mac.app.mp4

Mac app logs: mac-app-logs.zip

The Print report buttons and the user import option are working correctly.

Android app:

1. Clicking any of the download buttons at Facility > Data results in seeing the button in a pressed state without a clear indication that the download has started and completed. An experienced user can see that in the notification area but the user experience is not great. The same is valid for the Coach reports where clicking the Export as CSV button leaves it in a pressed state with the 'Export as CSV' tooltip remaining visible.

Android.download.mp4

[rtibblesbot]

Thanks — the two Mac problems are one cause, and both are fixed in 911cd52. The Android feedback point is 2c68bda.

Mac. wxPython's html2 uses WebKit on macOS, and that backend has no download support at all: an anchor's download attribute is simply ignored. So the Facility CSVs navigate the webview to the file and it renders as text in place of the page, and the coach export — whose link carries a data: URL with target="_blank" — hits WebKit's block on top-level data: navigation and does nothing whatsoever. Same missing capability, two different-looking symptoms.

The app now intercepts a[download] clicks in an injected script, reads the resource in the page (where the session cookie lives, so authenticated exports work), and hands the bytes to Python over the existing kolibriBridge to write out. What you'll see that's new: a Save dialog, defaulting to ~/Downloads and to the filename the server or the exporter supplied. Windows is untouched — WebView2 has its own download UI and you and @radinamatic have both already confirmed it works.

I have no macOS here, so this one is unverified beyond unit tests on the message handling. It needs a fresh DMG.

Android download feedback. Fair — the notification shade is the only signal today. There is now a toast on start, on completion and on failure, so something lands in front of the user without them going looking.

Android stuck button + tooltip. This one I'm leaving alone, and I don't think it belongs to this PR. It's sticky :hover — a touch device synthesises a hover on tap and holds it until you tap elsewhere, so the button keeps its hover styling and KTooltip (which is trigger="hover") keeps showing. You'll get the same behaviour tapping any icon button in Chrome on Android. The fix would be in kolibri-design-system, not here; happy to file it there if you'd like.

Both platforms need fresh builds.

---

Separately, a correction to my earlier note about tox.yml: I was wrong that adding platforms/** would make FileChooserUtilsTest run in CI. Nothing in .github/workflows invokes ./gradlew test — the platform_tests matrix is pytest for platforms/debian-server and platforms/desktop-app only, so the Android JVM tests run nowhere. All that entry actually did was un-skip the whole Python matrix, macOS rows included, on Java-only changes. Reverted in 1cf19f3.

[radinamatic]

Confirming that importing CSV files in latest Kolibri APK asset on Android is now working correctly for files located on the device. ✔️

However, the previously reported issue with server disconnect when trying to import the CSV file on Google Drive is still extant. Disregard, acknowledging that a follow up issue was filed.

[pcenov]

Mac app: I confirm both fixes - clicking a Download or Export as CSV button results in a Save dialog, defaulting to ~/Downloads:

mac-save.mp4

Android app: There's now a toast message which should be good enough for now:

Windows app: No changes.

[radinamatic]

LGTQATeam!!! 💯 🚀

[rtibbles]

The manual QA shows this is working, so mostly I am just interested in some cleanup here, while preserving the code as is.

If any of the tests are not giving us helpful coverage they should be removed or replaced.

When things have been fixed up, we should tidy up the commit history to give a logical story of how things are.

[rtibbles]

This feels concise enough to be inline, so this is OK.

[rtibblesbot]

Left inline as-is.

[rtibbles]

I think this script is extensive enough that I would prefer it be stored in a .js file and loaded to be used. If needs be. It may need some linting exclusion exceptions.

[rtibblesbot]

Moved to src/kolibri_app/scripts/download.js, read at import time via importlib.resources.files and passed through the same __BRIDGE__/__TYPE__ substitution as the inline print shim. Added the directory to datas_list in kolibri.spec so PyInstaller bundles it.

No lint exclusion turned out to be needed: lint-frontend globs {kolibri*/**/frontend,packages,build_tools}/**/*.{js,vue,...}, so nothing under platforms/ is linted (verified with a deliberately broken probe file — prek passed it). I kept a /* eslint-disable no-console */ at the top of the file anyway so editor ESLint integrations, which resolve the root config regardless of that glob, do not flag the console.error in the catch.

[rtibbles]

I have been iffy in the past about tests for the desktop app, as they have involved significant mocking of the wx APIs - how much value are these actually adding?

[rtibblesbot]

Fair question. I went through them and cut the ones that were really only asserting the shape of a mock call:

• test_offers_the_sanitised_name_as_the_default — deleted. It asserted wx.FileDialog.call_args.kwargs["defaultFile"], which is a mock-shape assertion that duplicates the direct _download_filename tests.
• test_print_message_defers_the_dialog — folded into test_repeated_print_messages_enqueue_one_dialog, which now asserts the target as well as the count, so nothing is lost.
• Added TestBridgeScripts — no wx at all; it catches scripts/download.js failing to load or shipping with the __BRIDGE__/__TYPE__ placeholders unsubstituted, which is now a real packaging failure mode after the change above.

On the mocking: the module-level sys.modules wx stub is not new here — it is the pattern already in test_kolibri_home_readable.py on develop; this branch only hoisted it into conftest.py so both modules share it. Beyond that the tests touch exactly two wx names, wx.CallAfter (a scheduling primitive) and wx.FileDialog (the OS file picker — a hard boundary), and what they assert is our logic, not wx:

• TestDownloadFilename — the path-traversal guard on a page-supplied filename. Pure function, no wx, and the one place a bug is a security bug.
• TestScriptMessages — the bridge dispatch contract: malformed or unknown JSON from the page must not blow up the handler, and repeated window.print() calls must not stack up dialogs (that coalescing is the non-obvious bit).
• TestSaveDownload — writes real bytes to a real temp file and asserts the content; the mock only stands in for the picker returning a path. Also covers "cancel writes nothing" and "undecodable base64 never opens the dialog".

If you would still rather not carry the two wx-touching classes, I am happy to drop TestScriptMessages and TestSaveDownload and keep only TestDownloadFilename and TestBridgeScripts — just say the word.

[rtibbles]

QA checks out, post-QA code changes minimal and make sense.