Bugzilla

(In reply to :Gijs (he/him) from comment #50)
> OK. Marco, do you have thoughts on how best to detect we're handling `.py` as `text/plain` and not offer the "always do this" checkbox in the unknownContentType dialog on Windows in this case (see comment #46 for context) ?

First, I read again all of the discussion taking a bit more time, I think bz's proposal to change the handler search order makes sense, as well as your proposal to hardcode text/plain for things in the ApplicationReputation list.

For the handling, it's not very different from what we do for octet-stream here https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/toolkit/mozapps/downloads/HelperAppDlg.jsm#512 so it sounds like we should be able to just add another case. We have both the url and the type there.
That will uncheck the checkbox and disable it. This UX choice is ugly, imo. The user doesn't know why this checkbox gets disabled, and the explanation is too complicate to show it. I think we should actually hide/collapse the checkbox and not show it, that is closer to a "we show you the feature only if the website supports it". It would be less frustrating for the user.

There is actually a difference from octet-stream, for which we never want to remember the action; here we may want to remember the action if the user changes the handler in the dialog to one valid for the extension (and it's real type)... Unfortunately this would require the dialog to know all the handlers for the extension, and onchange check if the picked handler is in that list. That sounds over complicate and unnecessary.
In the end I'd just remove the checkbox and file Tech Evangelism bugs to ask servers to serve files with proper types...

If your question was wider, please let me know.

(In reply to :Gijs (he/him) from comment #50)
> OK. Marco, do you have thoughts on how best to detect we're handling `.py` as `text/plain` and not offer the "always do this" checkbox in the unknownContentType dialog on Windows in this case (see comment #46 for context) ?

First, I read again all of the discussion taking a bit more time, I think bz's proposal to change the handler search order makes sense, as well as your proposal to hardcode text/plain for things in the ApplicationReputation list.

For the handling, it's not very different from what we do for octet-stream here https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/toolkit/mozapps/downloads/HelperAppDlg.jsm#512 so it sounds like we should be able to just add another case. We have both the url and the type there.
That will uncheck the checkbox and disable it. This UX choice is ugly, imo. The user doesn't know why this checkbox gets disabled, and the explanation is too complicate to show it. I think we should actually hide/collapse the checkbox and not show it, that is closer to a "we show you the feature only if the website supports it". It would be less frustrating for the user.

There is actually a difference from octet-stream, for which we never want to remember the action; here we may want to remember the action if the user changes the handler in the dialog to one valid for the extension (and its real type)... Unfortunately this would require the dialog to know all the handlers for the extension, and onchange check if the picked handler is in that list. That sounds over complicate and unnecessary.
In the end I'd just remove the checkbox and file Tech Evangelism bugs to ask servers to serve files with proper types...

If your question was wider, please let me know.