Side-loaded extensions are not prompted to be enabled for private browsing
Categories
(WebExtensions :: General, defect, P1)
Tracking
(firefox-esr60 unaffected, firefox66 unaffected, firefox67 verified, firefox68 verified)
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox66 | --- | unaffected |
firefox67 | --- | verified |
firefox68 | --- | verified |
People
(Reporter: jocodes, Assigned: rpl)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [qa-triaged])
Attachments
(3 files)
(deleted),
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details |
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
Steps to reproduce:
sudo cp $myext '/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/
firefox-nightly &
Actual results:
Firefox started, prompted me to enable the side-loaded extension, but never said a word about private mode. The extension did not have private mode access.
Expected results:
Arguably, a prompt for access to private mode should be given at installation time, similar to the prompt given for web-installed extensions.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Can we get a good manual STR for this as well?
Comment 4•5 years ago
|
||
I want to be really clear on the issue we're looking at here: is this only about private mode, or about sideloading in general? This is filed against the 67 branch, but the user agent implies a version prior to the private browsing mode changes.
Comment 5•5 years ago
|
||
(Also, I want to be clear on whether sideloading fails, or it's just about having the option to enable the extension for PBM, as Shane's test yesterday failed to even sideload, iirc.)
Sideloading succeeds. The issue is that after sideloading succeeds, the extension is not allowed in private windows, and the user is never prompted to make a decision about that, unlike what occurs when an extension is installed from AMO.
If it is helpful, I can attach a sideloaded extension, but any signed extension will do.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Distribution_options/Sideloading_add-ons documents the extension folders for each platform.
Also, bug 1533638 has a test case that demonstrates sideloading; might be of some use in this bug too.
Updated•5 years ago
|
Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/9bc49a9e915a Show post install notification when enabling sideload extensions. r=mixedpuppy,kmag
Comment 9•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
I was able to reproduce the issue on Firefox 67.0b5 (20190325125126) under Win 7 64-bit and Mac OS X 10.14.1.
This issue is verified as fixed on Firefox 68.0a1 (20190326095147) under Win 7 64-bit and Mac OS X 10.14.1.
Please see the attached video.
Comment 11•5 years ago
|
||
Comment on attachment 9049510 [details]
Bug 1533172 - Show post install notification when enabling sideload extensions. r?mixedpuppy!
Beta/Release Uplift Approval Request
- Feature/Bug causing the regression: Bug 1380809
- User impact if declined: Sideloaded extensions require two manual steps by the user to enable and turn on in private windows. This makes the post install panel appear for those situations after the user has enabled the extension, making UX better for the user.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): minimal change limited to sideloaded extensions
- String changes made/needed: none
Comment 12•5 years ago
|
||
Comment on attachment 9049510 [details]
Bug 1533172 - Show post install notification when enabling sideload extensions. r?mixedpuppy!
Less confusing UX for our we bextention changes in private browsing mode, has tests and was verified on Nightly by QA, uplift approved for 67 beta 6, thanks.
I'd like it to be verified by QA in Beta as well.
Updated•5 years ago
|
Comment 13•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Comment 14•5 years ago
|
||
This issue is verified as fixed on Firefox 67.0b6 (20190328152334) under Win 7 64-bit and Mac OS X 10.14.1.
Please see the attached video.
Updated•5 years ago
|
Updated•5 years ago
|
Description
•