Closed HighCommander4 closed 6 years ago
The way I did it was creating a whitelist of text/... MIME types that firefox recognizes and then treating all other MIME types as foreign... its a bit risky though.
Optimally, we could integrate the UI into the already existing dialog, then we wouldn't have to duplicate all the logic: https://bugzilla.mozilla.org/show_bug.cgi?id=1344648
The way I did it was creating a whitelist of text/... MIME types that firefox recognizes and then treating all other MIME types as foreign... its a bit risky though.
What I'm doing is reading through Firefox's source code to understand when Firefox decides to show the dialog, and try to replicate that. The logic is quite complicated, and it is likely that for some types I will display a dialog even though the current action is to not show a dialog. However, the user can permanently save a choice so that the dialog won't appear again.
It seems that nsDocumentOpenInfo::OnStartRequest
is the entry point, and nsDocumentOpenInfo::DispatchContent
is first callee that makes decisions on whether to open the dialog or not.
Before looking through the above code, I already found a list of some common types by searching for "Gecko-Content-Viewers"
:
( the constants are defined in https://searchfox.org/mozilla-central/rev/56ad02e34d0d36ca4d5ccaa885d26aff270b8ff7/netwerk/mime/nsMimeTypes.h )
Optimally, we could integrate the UI into the already existing dialog, then we wouldn't have to duplicate all the logic: https://bugzilla.mozilla.org/show_bug.cgi?id=1344648
That would be ideal, but not feasible for Firefox 57.
Some update: Last month I spent two weeks on learning and documenting the intrinsics of Firefox's content handling logic and implemented it so that the extension behaved identical to Firefox in terms of content handling. Unfortunately, right after I finished but before I pushed the changes my laptops were stolen, and I don't have the time nor motivation to redo this work at this time.
I will try to update the MIME lists to match Firefox's because that is the common case.
In case anyone wants to contribute to a content sniffer, I posted a guide for the implementation at #5. The logic is non-trivial, so please include some tests and make sure that these pass.
@Rob--W that sounds horrible! Hope you are doing well :heart: :)
As mentioned here, this is one of the missing pieces of functionality compared to @est31's version. It would be great to have this added :)