happ get's stuck on spinning wheel in tauri window

[matthme]

Describe the bug trying to use the 0.0.17 version of the playspace the screen turns blank on the resource page or when putting a resource in a plan

[adaburrows]

It's likely because of this config option: https://tauri.app/v1/api/config/#windowconfig.filedropenabled

I could probably create a workaround, since we don't actually need to read any of the data from the drop event. I can just store it in the app's data store and we can work around it.

The other part of the problem was the page routing. It turns out of I use the in memory router then the app seems to work just fine when we reload it (though it looses track of where the user was).

The answer to this probably needs to be in another ticket, but I'm also wondering about the security policies and which domain or security realm is used for front end for apps in Tauri. Can I write to local storage and other have other apps read it? In previous versions, since the launcher used different ports, each app had its own security context.

[matthme]

Thanks for digging into it! If it's indeed the file_drop_enabled option that part should be easy to fix. What's a bit unfortunate is that changing this setting would then potentially oppose the needs of other apps that might want to use the file drop event. However I currently think having file drop disabled by default is the better option and we might think about introducing something like a launcher-config where an app could still explicitly specify to prefer file drop instead...

Regarding routing and local storage I haven't looked into it deeply yet how that's handled by tauri. I will do that once I have more time, it's definitely something we need good solutions for.

[adaburrows]

To summarize issues found so far:

• When a path is not found, it doesn't load the index.html. This interferes with pushstate application routing. (Fixed in experiment-asset-loading; it should probably be changed to be configurable based on the app, but the console warning about it is probably sufficient).
• When a drag and drop event occurs, Tauri is configured to expect a file drag and drop event. (Fixed in https://github.com/holochain/launcher/commit/f08db1f914872d3cb2805867f54f79329f5af418)
• Additionally, applications need to have <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> meta tag to ensure the correct charset is chosen -- just incase the set_mimietype fix doesn't work. (For instance, I didn't see if it properly checks and sets it again after defaulting to index.html.)

[matthme]

Thanks for summarizing. Point 1 is also already implemented in the currently most up-to-date branch (signing-zome-calls).

About point 3, it does set the MIME type to "text/html" in case it redirect's to the app's index.html, like here: https://github.com/holochain/launcher/blob/f08db1f914872d3cb2805867f54f79329f5af418/src-tauri/src/launcher/manager.rs#L504

just incase the set_mimietype fix doesn't work

I don't think that's the problem, the problem is the encoding/charset only (which is usually provided together with the MIME type in the "Content-Type" field of the HTTP header but is distinct from the MIME type). And opposed to the MIME type, the encoding/charset cannot be set by tauri it seems.

[adaburrows]

The weird thing is that it uses the the Response::mimetype field to build the content-type header it passes to wry (the webview library), see:

• https://github.com/tauri-apps/tauri/blob/3dc38b150ea8c59c8ba67fd586f921016928f47c/core/tauri-runtime-wry/src/lib.rs#L297
• https://github.com/tauri-apps/wry/blob/ddd34614be8a0ba826eff8acbf4b06710ce2ba65/src/webview/webkitgtk/web_context.rs#L332
• https://github.com/tauri-apps/wry/blob/ca7c8e44832b3236f08022f7ea3469be9a65aa3f/src/webview/wkwebview/mod.rs#L186
• (Android webview) https://github.com/tauri-apps/wry/blob/7f585c7dc947936387faf565f3f5cbe62148daaf/src/webview/android/binding.rs#L84 (has specific logic to look for the charset= part in https://github.com/tauri-apps/wry/blob/7f585c7dc947936387faf565f3f5cbe62148daaf/src/webview/android/binding.rs#L91)

So, I'd think it would be possible to set the full content type header, like so:

response.set_mimetype(Some(String::from("text/html; charset=utf-8")));

If you tried it and it didn't work, then there must some conditional that prevents it from using that value at some intermediary point. At any rate, it should be documented somewhere that all launcher applications should make sure the use the right <meta> tag.

[matthme]

Okay, I see now. They indeed seem to equate MIME type with Content type (which I think is not correct). Thanks for pointing that out! However I'm not sure the launcher can just add the encoding itself there because it has no way to know what the right encoding is supposed to be, I think. I could just always add utf-8 but that seems like it might be a problem in case the application expects something else. I wonder what would take precedence in case of conflicting encodings, the HTTP header or the meta tag? If the meta tag would anyway take precedence then maybe adding utf-8 to the HTTP header by default is safe...

[adaburrows]

Ah, yes. Good point. If they intend to do something weird, then you cannot set the header type because that would take precedence over the http-equiv meta tag.

We need to ensure all app developers know to ensure the proper http-equiv meta tag is set for their local or preferred encoding (for those who prefer to use the antiquated x-mac-roman or FIELDATA-UNIVAC, or if you happen to be in China and use GB18030).

Here's a good link for beginner devs: https://www.w3.org/International/questions/qa-what-is-encoding

[matthme]

Closing this because the issues have been addressed in the meantime.