1404717 - Change of brandFullName causes issue with default browser on macOS

Status: RESOLVED WONTFIX

(Firefox :: Shell Integration, defect)

Description

[Sören Hentzschel]

Attachment: screenshot

Please see the attached screenshot. The screenshot is in German (sorry for that), it's the default browser dialog of macOS. The operating system thinks that "FirefoxNightly" is another browser than "Nightly". It's probably a consequence of bug 1378834, at least I don't see no other relation. Please note that this dialog didn't appear after the first start with the new name but after the second or third (I am not sure).

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Gijs, do you know anything about the default browser mechanism on Mac? Thanks

Comment 2

[Albert Scheiner [:alberts]]

Attachment: Screen Shot 2017-10-02 at 06.25.37.png

I got a second message in this context after opening the latest FirefoxNightly for the first time - just putting it out there, though this might be necessary.

Comment 3

[:Gijs (he/him)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #1)
> Gijs, do you know anything about the default browser mechanism on Mac? Thanks

Not really, unfortunately. Maybe :spohl does. But given comment #0 and the uncertainty about how many restarts it took etc., perhaps it would be useful if QA could narrow down steps to reproduce?

FWIW, my /Applications/ copy of Nightly has always (since 2014, as far as I can tell) been "FirefoxNightly.app" (but it's also not my default, so...) so I'm not sure what the relation is between the app name, the configure.sh change, the app filename, and how that works with upgrades, and finally with OS X's default browser UI.

Finally I doubt, given how OS X locks this down, that we could do anything about it (short of renaming things back to Nightly.app, if indeed that's a thing, and if we would consider doing it). As a one-time hoop for people on OS X to jump through on an alpha channel it seems annoying but also, now that it's already happened, like it's too late to mitigate it. Most users will have already updated by the time we get certainty on a diagnosis, an approved patch, and that makes nightly -- and another rename would simply cause the same problem a second time.

Comment 4

[Stephen A Pohl [:spohl]]

(In reply to :Gijs from comment #3)
> (In reply to Sylvestre Ledru [:sylvestre] from comment #1)
> > Gijs, do you know anything about the default browser mechanism on Mac? Thanks
> 
> Not really, unfortunately. Maybe :spohl does.

See bug 1378834 comment 38.

Comment 7

[Robert Strong (they/them - no direct email)]

Syvestre, what do you want to do with this bug since there isn't anything that can be done in shell integration to fix it. As I see it your choices are to either leave it as is and let clients manually fix it on Nightly or backout your changes in bug 1378834 and clients that have manually fixed it can fix it again.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Is there a way on Mac OS X level to tell to the operating system "I am renaming the package, it is normal, please consider that it is the same"?

For now, the first option is the least bad of the two but it isn't great :/

Last but not least, would it be a better way to manage that for the future? On Android, Linux & Windows, it didn't cause any issue afaik.

Comment 9

[Robert Strong (they/them - no direct email)]

iirc the last time this happened no one came up with a method.

Stephen, can you answer Sylvestre's question?

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Moreover, in bug 1404796, I said that I should add a missing space in the package name...
I am afraid that this bug will happen again if I do that.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

We disabled nightly updates on mac until we make a call on that.

Comment 12

[Justin Dolske [:Dolske]]

Can we just back that change out? People are still busy with final 57 work, and in particular our macOS experts (spohl/mstange) are chasing down important 10.13 regressions.

I'm a little surprised we did this right now -- these were exactly the kinds of problems we expected when it came up in early discussion of a deeper "Firefox Quantum" rebranding, and we punted on that because of the risk of poorly-timed regressions (among other reasons).

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Justin, sure, we can backout the changes, no worries.
If I knew that the Mac packaging was so fragile (no offense), I would have waited after the 57 go live...

Comment 14

[Stephen A Pohl [:spohl]]

I was just going to comment when I realized we're going to back this out. Here are my thoughts for next time we're trying to tackle this:

Personally, I think we should back out the name change (at least on Mac) and give this some thorough testing with QE's help on a branch like Oak first. The number of unforeseen issues would seem to make this the prudent path forward. My suggestion would be to:
1. List the various issues;
2. List the impact on end-users as well as extension developers for each issue;
3. Make a deliberate call for each issue to either mitigate it beforehand, or accept the disruption as a one-time cost of this change.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

So, I landed everything on the oak branch. QE verified the build and didn't see any issue.
AFAIK, we cannot fix this issue. So, we will live with this issue.