[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.

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.

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.

(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.

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...

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

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.

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

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

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.

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

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

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

(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 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

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 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.

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

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.