[BUG] Incorrect .html file extension of exported tiddlers on Android

[mateuszwilczek]

Describe the bug

Exporting (downloading) a tiddler or filter results on Android results in an incorrect extension of the downloaded file:

• in Chrome-based browsers: .html appended, e.g. HelloThere.json.html instead of HelloThere.json,
• in Firefox: .html replaces the expected extension, e.g. HelloThere.html instead of HelloThere.json.

Expected behavior

The exported tiddlers or search results in TID or JSON format should have the correct, expected extensions on all platforms, that is .tid or .json.

To Reproduce

1. Go to tiddlywiki.com on Android
2. Export a tiddler or filter search results
3. The downloaded file will have .html extension instead of the expected .tid or .json.

Screenshots

No response

TiddlyWiki Configuration

• TiddlyWiki v5.3.6, bug appears the same on v5.1.5 (the first version with export functionality)
• Android 14
• Browsers: current as of 2025-01-07 versions of Chrome, Brave, and Firefox for Android
• I could not reproduce the issue on Chrome on iOS (the downloaded file has the expected extension), so this bug seems Android specific

Additional context

The contents of the downloaded files appear unremarkable, renaming them makes them completely usable.
It's an inconvenience though, especially when one wants to quickly export a tiddler from one wiki and import to another on an Android device – the file won't be correctly recognized and imported as a tiddler if it has the .html extension, even if it contains valid TID or JSON data.

[Jermolene]

Thanks @mateuszwilczek

I think that this bug is probably a symptom of the way that the text/html type is baked into the download saver:

TiddlyWiki5/core/modules/savers/download.js

Lines 37 to 42 in f8a8f00

	if(Blob !== undefined) {
	var blob = new Blob([text], {type: "text/html"});
	link.setAttribute("href", URL.createObjectURL(blob));
	} else {
	link.setAttribute("href","data:text/html," + encodeURIComponent(text));
	}

It would take a bit of analysis to figure out if we could pass the correct mime type through the chain to get to the saver somehow.

[cdaven]

It would take a bit of analysis to figure out if we could pass the correct mime type through the chain to get to the saver somehow.

May I suggest that you instead infer the MIME type from the filename variable? I did that in my workaround for downloading .zip files:

https://github.com/cdaven/tiddlywiki-stuff/blob/51351eec73895fa65ea60122fd0d720c90f35f0a/markdown-export/download-saver.js.tid#L30C2-L36C3