1535080 - File picker for selecting default handler application for protocol scheme (e.g. mailto:) not opening/broken in Options/Preferences > General > Applications > "Use other..."

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P1)

Description

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

[Tracking Requested - why for this release]:
Broken preferences feature (regression)

Firefox Nightly 67.0a1 20190313100914 on Windows 8.1

The file picker for selecting the default handler application for a protocol scheme (e.g. mailto:" doesn't open when one clicks "Use other..." from the dropdown for a protocol and then on "Browse".

Steps to reproduce:

1. Open Options/Preferences > General > Applications
2. For mailto, open the dropdown and click on "Use other..."
3. Click on "Browse..."

Actual result:
Nothing happens.

Expected result:
File picker opened.

Jonas, can you take care of this? It's from bug 1525636.

Comment 1

[Jonas Allmann [:jallmann]]

I would have liked to fix this, but I just noticed this appears to be a Windows only issue, and I'm working on Linux, so I can't reproduce it.

Comment 2

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

The addEventListener is not reached (more info in bug 1535087). Putting at the start of the method fixes it.

How can this be tested? Selecting the dropdown for mailto triggers the favicons for the web protocol handlers to be fetched which causes a FATAL ERROR for the non-local connection and overwriting gecko.handlerService.schemes.mailto.* doesn't fix it because these prefs only get read when the profile gets created.

Gijs, any suggestions on that? Thank you.

Comment 3

[:Gijs (he/him)]

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #2)

How can this be tested? Selecting the dropdown for mailto triggers the favicons for the web protocol handlers to be fetched which causes a FATAL ERROR for the non-local connection and overwriting gecko.handlerService.schemes.mailto.* doesn't fix it because these prefs only get read when the profile gets created.

Gijs, any suggestions on that? Thank you.

See the code at the top of https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/tests/browser_applications_selection.js

It's probably easiest to add a test to that file.

Comment 4

[:Gijs (he/him)]

See also https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/tests/browser_change_app_handler.js, fwiw, which does attempt to test this, AFAICT...

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Is comment 2 to comment 4 enough information to put together a patch for this, Jonas?

Comment 6

[:Gijs (he/him)]

This is a recent regression and it's tracking 67 -> P1.

Jonas, if you can't take this (see comment #5) please let us know ASAP, and ideally try to find another owner.

Comment 7

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

The short term fix is to move the addEventListener up, see comment 2. Can look more into it after today.

Comment 8

[Jonas Allmann [:jallmann]]

Attachment: Bug 1535080, Fix file picker not opening on Windows, r=gijs

Move addEventhandler to top of appPickerLoad() to avoid not reaching it when errors occur later in the function.

Comment 9

[Jonas Allmann [:jallmann]]

This really just moves the addEventhandler(), as suggested by aryx.
I haven't looked into the test situation, that would take me a little longer to get familiar with.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dca8a22066e8
Fix file picker not opening on Windows, r=Gijs

Comment 11

[:Gijs (he/him)]

We should probably consider still adding a test for this behavior.

Comment 12

[Natalia Csoregi [:nataliaCs]]

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

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Jonas, since 67 is marked as affected, should we consider uplifting this to Beta67? If yes, please nominate a patch for uplift.

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Ritu Kothari (:ritu) from comment #13)

Hi Jonas, since 67 is marked as affected, should we consider uplifting this to Beta67? If yes, please nominate a patch for uplift.

Gijs, Jonas currently works only one day a week and i am not sure I know the answer. Do you think we need to uplift that change?

Comment 15

[:Gijs (he/him)]

Comment on attachment 9053524 [details]
Bug 1535080, Fix file picker not opening on Windows, r=gijs

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 1525636
• User impact if declined: Broken dialog in the prefs
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: see comment #0
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Moving an event listener so it still gets added if the function it's in returns early - 1 line of JS being moved around - is not risky.
• String changes made/needed: Nope

Comment 16

[Paul_B]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Build ID: 20190402083512

Verified as fixed using the latest Nightly build. The file picker now opens when the "Browse" button is selected.

Comment 17

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9053524 [details]
Bug 1535080, Fix file picker not opening on Windows, r=gijs

Low risk fix for a 67 regression, uplift accepted for 67 beta 8, thanks.

Comment 18

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/releases/mozilla-beta/rev/734b7738a6c4

Comment 19

[Paul_B]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Build ID: 20190404130536

Verified as fixed using the latest DevEdition (67.0b8) build. The file picker opens when the "Browse" button is selected.