1448374 - Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Alexander O'Mara]

Attachment: test-extension.zip (WRONG VERSION, USE THE UPDATED VERSION)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180315233128

Steps to reproduce:

It may sound strange, but I swear this is all true.

I've created a GitHub Gist for this issue here: https://gist.github.com/AlexanderOMara/6a9a5ac610078a70b49353b41b2dbda2

I've also created a video of the issue here: https://www.youtube.com/watch?v=VNKD40UspzM

----

Loading a `.javascript` file from a WebExtension's [web_accessible_resources](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources) somehow causes problems with the macOS file associations, most notable so with TextMate 2.

Tested On:

-   macOS 10.13.3 (native and in a clean VM)
-   Firefox 59.0.1 (Stable)
-   Firefox 60.0b5 (Developer Edition)
-   Several previous Firefox versions

Reproduce Instructions:

1.  Download this Gist if you have not already.
2.  Install [TextMate 2 RC 8](https://github.com/textmate/textmate/releases/download/v2.0-rc.8/TextMate_2.0-rc.8.tbz) (exact version probably does not matter).
3.  In Finder navigate to the Gist, select `file.js` and `file.txt`, click File > Get Info, and set all of them to open with TextMate, making sure to click "Change All" for each one.
4.  Make sure TextMate is not running, then open Firefox 59.0.1 (exact version probably does not matter), ideally with a new profile.
5.  Go to `about:debugging`, click "Load Temporary Add-On" and open the `manifest.json` file in this Gist.
6.  Verify in Finder that TextMate is still the default editor for `.js`, and `.txt` files.
7.  Go to a page that loads `google-analytics.com/analytics.js`, like [this minimal one](https://cdn.rawgit.com/AlexanderOMara/485d4a794eb861dc36745a85503edea2/raw/523fe64b31abb33fb844bd39b771dd51b7f7d3f8/index.html).
8.  In Finder, select `file.js`, and `file.txt` again and click File > Get Info and see that it has changed (you can also try opening them to confirm it has changed).
9.  Open TextMate.
10. Repeat step 8 to see it has actually changed back.
11. Reload the page from step 7 to see it change again.

Notes:

-   You can simply refresh the page to see the issue repeat.
-   You can edit `background.js` to load `war-test.js` instead of `war-test.javascript` and see the issue no longer happens.
-   Other extensions do not seem to cause the problem, it seems something is special about the `.javascript` extension.
-   If the `moz-extension://` URL is known and added to the DOM, it is possible to trigger the issue without a `onBeforeRequest` redirect.
-   Requests to `.javascript` files outside of `web_accessible_resources` does not cause an issue.
-   Current versions of uBlock Origin (1.15.12+, since [this commit](https://github.com/gorhill/uBlock/commit/17930cc778c20e11fd4c760d710e8ba619aab666)) also causes this issue.



Actual results:

When the `war-test.javascript` file is loaded, Firefox somehow changes the file associations on some files. This specifically happens on `.javascript` files, and not `.js` files or any other extension I've tried.


Expected results:

Nothing should have happened, Firefox should not have touched the users file associations.

Comment 1

[Alexander O'Mara]

Attachment: test-extension.zip (correct version)

Comment 2

[Alexander O'Mara]

For reference, uBlock Origin has applied a change to work around this issue since 1.15.19b2 (https://github.com/gorhill/uBlock/issues/3636) so future release versions will probably will not trigger this bug, but the (updated) attachment test-extension.zip and Gist will continue to do so.

Comment 3

[ovidiu boca[:Ovidiu]]

Hi Alexander,

I tested this issue with FF Nightly 61.0a1(2018-03-27) and I can't reproduce it.
 Can you please retest this using Nightly? Here is a link from where you can download it: https://nightly.mozilla.org/

Comment 4

[Alexander O'Mara]

(In reply to ovidiu boca[:Ovidiu] from comment #3)
> Hi Alexander,
> 
> I tested this issue with FF Nightly 61.0a1(2018-03-27) and I can't reproduce
> it.
>  Can you please retest this using Nightly? Here is a link from where you can
> download it: https://nightly.mozilla.org/

Yep, it still happens on Nightly 61.0a1 (2018-03-27), as well as today's nightly 61.0a1 (2018-03-28).

Comment 5

[ovidiu boca[:Ovidiu]]

Thanks for your reply, I will set a component that I think is the appropriate one and well see what is the opinion of the development team.

Comment 6

[Ralf Vitasek]

I initially set the Bug as confirmed since i too observed the problem but for me it was Sublime Text on Mac which for me was the editor associated to .rb files and it started to reset that to system default XCode.  Whenever i manually changed back the association it always reverted to XCode a few minutes later.

After i updated to the provided Beta Add-On of uBlock Origin the Problem went away.

Initially observed this with the Beta Channel 60.0b5.

Comment 7

[Andrew Swan [:aswan]]

Extensions don't do anything that affects the underlying OS file associations.  I believe those are manipulated from the protocol handling code.

Comment 8

[Valentin Gosu [:valentin] (he/him)]

From what I can tell, this is a Mac issue. The code involved is most likely uriloader/exthandler/mac/*

(In reply to Andrew Swan [:aswan] from comment #7)
> Extensions don't do anything that affects the underlying OS file
> associations.  I believe those are manipulated from the protocol handling
> code.

I don't see anything in the protocol handling code that could change the default handler for external applications.

Comment 9

[Stephen A Pohl [:spohl]]

Could you run mozregression[1] to see if this is a regression? If you have never run mozregression before, simply run these three commands in a Terminal window:

sudo easy_install pip
sudo pip2 install -U mozregression --ignore-installed
mozregression

This bug reminds me of bug 1437281. However, that bug dealt with dragging of images to the Desktop.

Comment 10

[Stephen A Pohl [:spohl]]

... and the link to mozregression:

[1] https://mozilla.github.io/mozregression/

Comment 11

[Alexander O'Mara]

I had to create a different extension to go back far enough (https://gist.github.com/AlexanderOMara/8aba49e89cdff93e4f5b1383be115d99), but here are the results:

31:45.90 INFO: Last good revision: ba8db0fbc00605d6d097dde0b7e034297f55c1ec
31:45.90 INFO: First bad revision: 6b101438c684bff925471edbfe593e500bcb3a03
31:45.90 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ba8db0fbc00605d6d097dde0b7e034297f55c1ec&tochange=6b101438c684bff925471edbfe593e500bcb3a03

Comment 12

[Alexander O'Mara]

Attachment: test-extension-2.zip (more-backwards-compatible extension)

Comment 13

[Alexander O'Mara]

Based on that commit I tried setting security.sandbox.content.level to 2 in about:config with the current Firefox Developer Edition and the bug does not happen when I do that, so it's apparently dependent on some change made by that preference.

Comment 14

[Stephen A Pohl [:spohl]]

Haik, any thoughts? It seems unlikely, but is there any chance that bug 1437281 would fix this too?

Comment 15

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #14)
> Haik, any thoughts? It seems unlikely, but is there any chance that bug
> 1437281 would fix this too?

This bug is probably caused by the same underlying issue as bug 1437281, but the fix for bug 1437281 is specific to drag-and-drop so I expect we'll need a different fix to address this one. I'll try and reproduce this tomorrow and see what's happening.

This odd bug is caused by trying to use the MIME service from the content process which (due to sandboxing) isn't able to read from /Applications. As a result, when we call into Mac OS libraries to give us the default application for a given file type, the failure to read from /Applications causes the file associations to fall back to default or unexpected values.

We have bug 1446549 filed to address this general problem.

Comment 16

[Haik Aftandilian [:haik]]

Thanks for providing the reduced test case.

I did some debugging and confirmed that the call to LSGetApplicationForInfo() from GetMIMEInfoFromOS() in a child process is what is triggering this (see comment 15 for how its a sandboxing interaction). I'll work on getting this fixed. And the posted fix for bug 1437281 is not going to address this problem. Here's the stack I saw for the call to LSGetApplicationForInfo().

  * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0 LaunchServices`LSGetApplicationForInfo() 
    frame #1 XUL`nsOSHelperAppService::GetMIMEInfoFromOS() at nsOSHelperAppService.mm:355
    frame #2 XUL`nsExternalHelperAppService::GetMIMETypeFromOSForExtension() at nsExternalHelperAppService.cpp:2891
    frame #3 XUL`nsExternalHelperAppService::GetTypeFromExtension() at nsExternalHelperAppService.cpp:2682
    frame #4 XUL`nsExternalHelperAppService::GetTypeFromFile() at nsExternalHelperAppService.cpp:2817
    frame #5 XUL`nsExternalHelperAppService::GetTypeFromURI() at nsExternalHelperAppService.cpp:2744
    frame #6 XUL`mozilla::net::NewSimpleChannel() at ExtensionProtocolHandler.cpp:808
    frame #7 XUL`mozilla::net::NewSimpleChannel() at ExtensionProtocolHandler.cpp:830
    frame #8 XUL`mozilla::net::ExtensionProtocolHandler::SubstituteRemoteFileChannel() at ExtensionProtocolHandler.cpp:867
    frame #9 XUL`mozilla::net::ExtensionProtocolHandler::SubstituteRemoteChannel() at ExtensionProtocolHandler.cpp:428
    frame #10 XUL`mozilla::net::ExtensionProtocolHandler::SubstituteChannel() at ExtensionProtocolHandler.cpp:452
    frame #11 XUL`mozilla::net::SubstitutingProtocolHandler::NewChannel2() at SubstitutingProtocolHandler.cpp:279
    frame #12 XUL`mozilla::net::nsIOService::NewChannelFromURIWithProxyFlagsInternal() at nsIOService.cpp:912
    frame #13 XUL`mozilla::net::nsIOService::NewChannelFromURIWithProxyFlagsInternal() at nsIOService.cpp:853
    frame #14 XUL`mozilla::net::nsIOService::NewChannelFromURIWithClientAndController() at nsIOService.cpp:754
    frame #15 XUL`NS_NewChannelInternal() at nsNetUtil.cpp:364
    frame #16 XUL`NS_NewChannel() at nsNetUtil.cpp:288
    frame #17 XUL`AsyncScriptCompiler::Start() at ChromeScriptLoader.cpp:102
    ...
    frame #167 plugin-container`start()

Comment 17

[Haik Aftandilian [:haik]]

I'm working on a fix that uses ContentHandlerService::GetTypeFromExtension(). I couldn't reproduce the problem with the fix installed. If any of the reporters is interested in testing the fix, a non-debug build of Nightly is available here.

  https://queue.taskcluster.net/v1/task/FHCEPadrTn6eNdkt49mGfQ/runs/0/artifacts/public/build/target.dmg

And here's a link to try results and code changes (so you know what you're downloading.)

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=2165ea22ca6f8f34e5561298507201cd86184b56

Comment 18

[Haik Aftandilian [:haik]]

Attachment: Bug 1448374 - Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations

From content processes, on Mac, use ContentHandlerService::GetTypeFromExtension()
instead of trying to query the OS directly for MIME information.
Trying to get MIME information from the OS is blocked by content process
sandboxing on Mac.

Review commit: https://reviewboard.mozilla.org/r/233502/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/233502/

Comment 19

[Haik Aftandilian [:haik]]

The posted fix uses ContentHandlerService::GetTypeFromExtension() to get the MIME type for a given filename extension from the parent instead of using the OS MIME API's from the content process. This is done using a sync message, but the results are cached so the impact of an additional sync message call should be minimal.

nsJARChannel calls nsIMIMEService::GetTypeFromExtension() in nsJARChannel::GetContentType(), but I don't think that is causing problems here. I'll investigate more and address that in an additional patch or new bug if necessary.

Comment 20

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #19)
> nsJARChannel calls nsIMIMEService::GetTypeFromExtension() in
> nsJARChannel::GetContentType(), but I don't think that is causing problems
> here. I'll investigate more and address that in an additional patch or new
> bug if necessary.

The fix already covers this case. The MIME service is implemented by nsOSHelperAppService which now handles directing the request to the parent if necessary.

Comment 21

[Jim Mathies [:jimm]]

Comment on attachment 8964769 [details]
Bug 1448374 - Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations

https://reviewboard.mozilla.org/r/233502/#review239476

lgtm

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b8847ae94ccf
Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations r=jimm

Comment 23

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/b8847ae94ccf

Comment 24

[Haik Aftandilian [:haik]]

Comment on attachment 8964769 [details]
Bug 1448374 - Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations

Comment on attachment 8955324 [details]
Bug 1448374 - Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations

Approval Request Comment
[Feature/Bug causing the regression]:
Bug 1332190, level 3 Filesystem Sandboxing on Mac.

[User impact if declined]:
Loading certain file types in the browser can cause OS X file associations (i.e., the configuration of which apps open which file types) to be reset to the system default which is very frustrating for users.

[Is this code covered by automated tests?]:
No

[Has the fix been verified in Nightly?]:
Only manually.

[Needs manual test from QE? If yes, steps to reproduce]: 
Yes. See description.

[List of other uplifts needed for the feature/fix]:
None

[Is the change risky?]:
No.

[Why is the change risky/not risky?]:
The changes are limited to Mac OS and rather straightforward.

[String changes made/needed]:
None

Comment 25

[Julien Cristau [:jcristau]]

Comment on attachment 8964769 [details]
Bug 1448374 - Loading a .javascript file from a WebExtension's web_accessible_resources messing with macOS file associations

fix regression from mac content sandboxing, approved for 60.0b12

Comment 26

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/6244d0e8ca93

Comment 27

[Anca Soncutean, Desktop QA]

I was able to reproduce this bug on Firefox 59.0.2 (20180323154952), under Mac OS 10.11.6, with the steps provided in the Description.
I retested everything, this time on Firefox 61.0a1 (20180416100103) and Firefox 60.0b12 (20180412172954), under Mac OS 10.11.6 and MacOS 10.13.3. The issue is no longer reproducible.

Comment 28

[u614529]

Firefox 61.0.2
Mac OS 10.11.6 El Capitan
15 August 2018

Uploading (not dragging) a photo to Twitter changed the computer's default program for opening a .jpg file from Preview to Firefox.

Uploading another photo to Twitter changed the computer's default program for opening a .txt file from TextEdit to Console.