Closed Bug 1402325 Opened 2 years ago Closed 2 years ago
Trying to load extension page results in "Access to the file was denied"
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36 Steps to reproduce: 1. Help > Troubleshooting Information > Refresh Firefox 2. Navigate to about:debugging#addons 3. Click 'Load Temporary Add-on' and select the attached XPI 4. Click the new toolbar button in the upper right 5. A panel showing 'Loaded!' should appear (resource://support-at-lastpass-dot-com/data/test.html) 6. Try to load the same page in a tab: resource://support-at-lastpass-dot-com/data/test.html Actual results: Access to the file was denied Expected results: The page should have loaded and 'Loaded!' should have been displayed
WFM in Fx55.0.3 & 56.0 on Win10.
As expected, Nightly 58, Beta 57 - There was an error during installation: Add-on email@example.com is not compatible with application version. add-on minVersion: 38.0a1. add-on maxVersion: *. For Fx 55.0.3, Fx 56.0 it's a works for me as well on Win 10. Asteel, is there something we are missing? Like a specific operating system or additional steps? Since we cannot reproduce it, marking as WFM. Please reopen with additional information.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Apologies, I actually missed the step 6, which was the thinghie we were supposed to see. So, I can't reproduce it in FF 55.0.3, but I can reproduce it on RC 6 - 56.0 Build ID 20170926190823, therefore reopening the issue.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Thanks Adrian! I was just about to suggest trying on a Mac, but if it's reproducible on windows too all the better!
More accurately, this is the changeset that introduced this regression: https://hg.mozilla.org/integration/mozilla-inbound/rev/5195f1b94903
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is probably a duplicate of bug 1393805. With the stronger filesystem sandboxing in build 56 (for Windows and Mac), legacy extensions can't be temporarily installed from arbitrary locations on the filesystem. The equivalent sandboxing should come to Linux in/around build 57. As a workaround, on Windows, could you try placing the extension in <user_home>\AppData\Roaming\Mozilla\Extensions and then installing? On Mac, as a workaround use ~/Library/Application Support/Mozilla/Extensions.
I just tried the workaround and got the same results. I loaded the XPI from /Users/asteel/Library/Application%20Support/Mozilla/Extensionsfirstname.lastname@example.org%20(1).xpi
(In reply to asteel from comment #7) > I just tried the workaround and got the same results. I loaded the XPI from > /Users/asteel/Library/Application%20Support/Mozilla/Extensions/ > email@example.com%20(1).xpi Which version of Firefox was that on? I'll post a screenshot of what it looks like for me. It installed for me on Mac FirefoxBeta 56.
I was on Mac Beta 56 and tried to make sure it was the latest 56 beta, but it downloaded 57 beta instead. Going to revert back to 56 now and will show a screenshot. How can I post a screenshot in a comment like this though? I don't see a way.
Haik, I see your screenshot now, that is the working case that you showed. Try loading resource://support-at-lastpass-dot-com/data/test.html in a new tab. I wanted to show the positive case as well to show the file was really accessible.
(In reply to asteel from comment #10) > I was on Mac Beta 56 and tried to make sure it was the latest 56 beta, but > it downloaded 57 beta instead. Ah, bad timing. The Beta channel just transitioned to 57, but Release is still on 55 (release date for 56 is tomorrow.) > Going to revert back to 56 now and will show > a screenshot. How can I post a screenshot in a comment like this though? I > don't see a way. Use the "Attach File" link under the attachments section and add your comment from the attachment upload page.
Here's a screenshot of the issue in 56.0b9 (https://ftp.mozilla.org/pub/firefox/releases/56.0b9/mac/en-US/)
(In reply to asteel from comment #11) > Haik, I see your screenshot now, that is the working case that you showed. > Try loading resource://support-at-lastpass-dot-com/data/test.html in a new > tab. I wanted to show the positive case as well to show the file was really > accessible. OK, I can reproduce that problem and can see what's happening now. The regular expression in the Mac sandbox rules for this directory has a very old bug that is exposed on build 56 when the directory is used. Could you try adding a 1-character subdirectory within the Extensions directory? For example, from the terminal, I create a new directory named 'X' and put the XPI in there. It has to be a 1-character directory. $ mkdir ~/Library/Application\ Support/Mozilla/Extensions/X $ mv support\@lastpass.com-1.1.1.xpi ~/Library/Application\ Support/Mozilla/Extensions/X/ I'll file a new bug for the regular expression issue which is only going to affect Mac build 56 and legacy extensions placed in ~/Library/Application\ Support/Mozilla/Extensions/. The plan with bug 1393805 is to provide a documented directory for developers to place legacy extension XPI's in for local development (to be loaded with about:debugging) for the next few releases until we've completely transitioned away from legacy extensions.
I'll confirm tomorrow once 56 is released :) My 56 test already auto-updated again.
(In reply to asteel from comment #15) > I'll confirm tomorrow once 56 is released :) My 56 test already auto-updated > again. OK, thanks. My trick is to create a new no-updates profile and with Release Firefox and turn off auto-updates in the preferences. Then launch my 56 download and choose the new no-updates profile. That requires starting Firefox with -P so that the profile manager comes up first ("/Applications/Firefox.app/Contents/MacOS/firefox -P") and then deselecting "Use the selected profile without asking at startup".
Priority: -- → P3
Jim, comment 14 and the progress in bug 1393805 make me think that this is wontfix/fix-optional for 56. What do you think?
(In reply to Panos Astithas [:past] (56 Regression Engineering Owner) (please ni?) from comment #17) > Jim, comment 14 and the progress in bug 1393805 make me think that this is > wontfix/fix-optional for 56. What do you think? I'll answer for Jim on this. I've been meaning to close this as a duplicate of bug 1393805. Bug 1393805 is going to provide a sandbox-whitelisted directory that a legacy extension could be copied to first and then installed with about:debugging for development. If we can get that uplifted to 56, it will serve as a workaround for this problem in 56.
Status: NEW → RESOLVED
Closed: 2 years ago → 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1393805
Marking fix-optional to get this bug out of the regression triage (we are tracking it in bug 1393805)
You need to log in before you can comment on or make changes to this bug.