Closed Bug 1508853 Opened 3 years ago Closed 3 years ago

Post install panel hides search opt-in panel

Categories

(WebExtensions :: Frontend, defect, P1)

64 Branch
defect

Tracking

(firefox-esr60 unaffected, firefox63 unaffected, firefox64+ verified, firefox65 verified)

VERIFIED FIXED
mozilla65
Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 + verified
firefox65 --- verified

People

(Reporter: deepak.gupta, Assigned: mixedpuppy)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce:

Do inline install of Extension that requires Search Override permission. Users have to opt-in for the permission after extension is installed. 

This is based of changes introduced for "Installation notification Prompt" described here https://blog.mozilla.org/addons/2018/11/08/extensions-in-firefox-64/


Actual results:

After extension is installed users get prompted with 2 notifications.
1. Opt-in for Search override permission
2. Installation notification Prompt

When user click on "OK" for Installation notification Prompt the Opt-in Permission automatically hides not giving users opportunity to take action.


Expected results:

Similar to addon installation experience in AMO Store users should be prompted for "Opt-In" Permission first and based on user action "Installation notification Prompt" should follow.
Product: Firefox → WebExtensions
Please provide an example of an add-on on AMO that has this issue.
Status: UNCONFIRMED → NEW
Component: Untriaged → Frontend
Ever confirmed: true
Priority: -- → P1
Summary: Users do not have opportunity to Opt-in for permissions on inline extension of install as notification popup for install is now persistent and clicking on the "OK" button hides Op-in Permissions. → Post install panel hides search opt-in panel
Shane, 

I am using nightly build 65.0a1 (2018-11-26) (64-bit)on Mac.

1. Addon published in AMO- https://addons.mozilla.org/en-US/firefox/addon/jobsrch/?src=search
2. Self hosted Addon distributed from - http://jobsrch.org/

Thanks,
Deepak
Blocks: 1491438
Attached image InstallPanels.png
The quick and simple fix is to change the persistent value to true.  This however results in the attached image.

https://searchfox.org/mozilla-central/rev/d35199ef15ffa57d190886e20d5df6471faf0870/browser/modules/ExtensionsUI.jsm#368
Also of note, this only affects search providers that set is_default: true in the manifest.
This is a quick fix to ensure that the search install panel is shown when an extension uses is_default.  The intention is to uplift for 64.
Assignee: nobody → mixedpuppy
Blocks: 1510298
Keywords: regression
Pushed by mixedpuppy@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/d40fbd0c1a77
make the search default panel persistent, r=aswan
See Also: → 1510353
https://hg.mozilla.org/mozilla-central/rev/d40fbd0c1a77
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
We're building the last 64 beta today, please request uplift asap.
Comment on attachment 9027919 [details]
Bug 1508853 make the search default panel persistent, r?aswan

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: None

User impact if declined: Users installing some search extensions will not get the panel asking about default setting

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: Yes

If yes, steps to reproduce: see original comment for STR

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): This is simply changing a boolean value for the search opt-in panel.  we have followup bugs to improve on the UI issues, this just makes it possible for the user to react to the panel.

String changes made/needed: none
Attachment #9027919 - Flags: approval-mozilla-beta?
Attached file Bug1508853.zip
I was able to reproduce this issue on Firefox 64.0b13(20181126173133) under Win7 64-bit and Mac OS 10.13.6.

On Firefox 65.0a1(20181128100125) under Win7 64-bit and Mac OS 10.13.6 I have the next scenarios:

For http://jobsrch.org/ the Search override permission is persistent with the confirmation pop-up but I have the next behaviors: 

- Clicking on the “OK” button from the confirmation pop-up will continue to display the Search override permission. 

- Switching the tab with the two pop-ups displayed, will display only the confirmation pop-up and dismiss the Search override permission. (Not sure about this one)

For https://addons.mozilla.org/en-US/firefox/addon/jobsrch/?src=search the Search override permission is displayed first and only after clicking “Yes” or “No” the confirmation pop-up is displayed. (Not sure about this one)

Also, if I switch the tab with the two pop-ups displayed, the Search override permission is dismissed and the confirmation pop-up is persistent. (Not sure about this one)

Are these the expected behaviors for this fix?
Flags: needinfo?(mixedpuppy)
> Also, if I switch the tab with the two pop-ups displayed, the Search
> override permission is dismissed and the confirmation pop-up is persistent.
> (Not sure about this one)

Please ignore this part from my previous comment, this behavior does not exist for the AMO scenario.
Switching tabs will dismiss the search prompt, that is expected behavior and is the same as before.

The post-install confirmation (off the menu button) is expected to be persistent until the user clicks it, regardless of tab/window switching.  The search prompt (off the url bar) is tab-modal and is dismissed if you switch tabs (and I think, if you switch windows), click anywhere else, etc.
Flags: needinfo?(mixedpuppy)
Comment on attachment 9027919 [details]
Bug 1508853 make the search default panel persistent, r?aswan

fix a regression in 64, per conversation with Shane the verification in nightly yields expected results; approved for 64.0b14
Attachment #9027919 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Thank you Shane!

According to Comment 11 and Comment 12, this issue is verified as fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
This issue is also verified as fixed on Firefox 64.0b14 (20181128185223) under Win7 64-bit and Mac OS X 10.13.6
You need to log in before you can comment on or make changes to this bug.