Open Bug 1600153 Opened 1 year ago Updated 25 days ago

macOS 10.15 Catalina - two firefox windows are opened when clicking on external link

Categories

(Core :: Widget: Cocoa, defect, P2)

70 Branch
Desktop
macOS
defect

Tracking

()

REOPENED
Tracking Status
firefox-esr68 --- fix-optional
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- fix-optional

People

(Reporter: blake, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Summary here - https://discussions.apple.com/thread/250833674?answerId=251702252022#251702252022

Since upgrading to catalina macOS, firefox has the following annoying property. If I click on a link outside of firefox (e.g. in a mail message), two firefox windows are always opened. The first one is blank while the second one contains the webpage of the link.

I've tried this with a new/fresh user account under Catalina. Same results... two firefox windows still open up when clicking an email link or link on the desktop.

Actual results:

two firefox windows are always opened. The first one is blank while the second one contains the webpage of the link.

Expected results:

only one window should open. other browsers work just fine.

Forgot to mention, this only happens when the Firefox application is not running.

Hi Blake,

Thanks so much for the details. I was able to reproduce this bug on Mac Catalina on Release 70.0 (64-bit) but not on Nightly 72.0a1 (2019-12-02) (64-bit) nor Beta 71.0 (64-bit). Which means that this bug has already been resolved and it will eventually work on future Firefox Release versions.

Firefox Nightly is made by codes and fixes made by Mozilla developers, that are compiled into a common code repository (Mozilla-central) to create a pre-release version of Firefox for testing purposes. After the code on Nightly matures, it is merged into stabilization repositories (Beta, ESR and Dev Edition) where that code will be polished until reaching the final version of Firefox (Release).

I leave you the link with the Firefox Release Calendar (https://wiki.mozilla.org/Release_Management/Calendar). When Release reaches Beta's (tomorrow) actual version (71) you will no longer encounter the problem.

I’ll mark this ticket as resolved since once the natural cycle is complete you won't have this bug; but feel free to reopen it if you experience this behaviour in the future once the migration to Release has been made.

Best regards, Flor.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME

Thank you Flor!

Multiple users are seeing that Release 70.0 is still showing the issue. Can you please take a second look, and make sure this bug is taken care of for the next release?

Thanks,
Blake

https://discussions.apple.com/thread/250833674?answerId=251702252022#251702252022

Hello,

Under Catalina 10.15.1 (19B88), I just updated Firefox to version 71 and Firefox Developer 72.0b2 and the bug is still present.

If Firefox is not open, all clicks on an external link (email, desktop, etc.) always open 2 windows (1 empty and then one containing the link)

It should reopen this bug, thank you in advance

Cordialy

Hello,

Under Catalina 10.15.1 (19B88), I just updated Firefox to version 71 and Firefox Developer 72.0b2 and the bug is still present.

If Firefox is not open, all clicks on an external link (email, desktop, etc.) always open 2 windows (1 empty and then one containing the link)

It should reopen this bug, thank you in advance

Cordialy

Hi,

Thanks for the details. I apologize for the inconveniences, you are correct, I was able to reproduce the bug on Mac Catalina on the following versions:

Release 71.0 (64-bit) and Nightly 73.0a1 (2019-12-04) (64-bit).

Doing a Mozregression by hand I noticed that this issue was created by version 72.0a1, build ID 20191201093732.

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Status: RESOLVED → REOPENED
Component: Untriaged → New Tab Page
Ever confirmed: true
Resolution: WORKSFORME → ---

Thank's Flor. ;-)

Component: New Tab Page → Widget: Cocoa
OS: Unspecified → macOS
Product: Firefox → Core
Hardware: Unspecified → Desktop

(In reply to Florencia Di Ciocco from comment #7)

Doing a Mozregression by hand I noticed that this issue was created by version 72.0a1, build ID 20191201093732.

Could you provide the URL to the regression range that mozregression returned for this?

Flags: needinfo?(florencia.di.ciocco)

Hi Stephen,

I cannot provide the URL since this is a bug that only happens if FF is not running, therefore Mozregression cannot be done (that is why I had to do it manually.)

Regards, Flor.

Flags: needinfo?(florencia.di.ciocco)

I misunderstood your comment 7 and thought you had figured out a way of running mozregression in this instance.

This is most likely a duplicate of bug 1580799.

Priority: -- → P2
See Also: → 1580799

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Same issue with Firefox 72.0.1 on macOS 10.15.2. Do not see this issue on a similarly configured system running macOS 10.14. Hoping for a fix soon, very annoying behavior.

Duplicate of this bug: 1606267

A colleague of mine who's experiencing this bug and I had a look at the code and found two possible sources of this bug:

  • There is a possible race condition between setting up the event handlers and nsCommandLineServiceMac::sBuildingCommandLine, statically set to false and set to true in the startup path, which can lead to two cmdLines being created: one in the main process startup path and one in the openURL-call created by the event handler, where nsCommandLineServiceMac::AddURLToCurrentCommandLine returns false because SetupMacCommandLine hasn't been called from the main thread yet.
  • openURL returns NO when the URL is added to the startup URLs. openFile returns YES in that case, which should be the correct return value, but I don't think it actually matters, since I don't see a caller that actually cares about the return value. I may have missed something, since I'm not familiar with the code.

I don't run macOS and don't have Objective-C++ experience, so I can't actually create a patch or test any of this.

After having had another look, the native event loop should not be running yet during the window for the aforementioned race condition, since it's started via XRE_mainRun which eventually calls nsAppShell:Run -> nsAppStartup::Run -> nsApp:Run, so this apparently can't be the cause :/

Duplicate of this bug: 1603425
Duplicate of this bug: 1627403

Please refrain from posting any more "me-too" comments. I have taken a look at this bug and the most promising approach is to rework the way we handle external links by not appending them to a "command line", but rather leverage our session restore mechanism in some shape or form. I have other important work to wrap up and will then take another look at this.

Hi, everyone -

This has turned into a bit of a pile-on, so I'm going to restrict this bug to editbugs-privileged users only. If anyone has something they would like to add to this bug that would materially move it towards a resolution or has any further concerns please fell free to contact me directly and I'll make sure to add it to the bug.

Please bear in mind that, like all Mozilla forums, Bugzilla is governed by the Mozilla Community Participation Guidelines as well as the Bugzilla etiquette guidelines, available here:

https://www.mozilla.org/en-US/about/governance/policies/participation/
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

As you can see from my colleague's description above, the solution to this bug is unlikely to be as simple and obvious as its symptoms; thank you for bearing with us while we prioritize and schedule the work we need to do to to get it fixed.

Restrict Comments: true
Severity: normal → S3
Duplicate of this bug: 1640394
Duplicate of this bug: 1646662
You need to log in before you can comment on or make changes to this bug.