Open Bug 1600153 Opened 4 months ago Updated 14 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: 4 months 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.

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 :/

I've noticed what might be another clue:

  • In the background window (with no content - blank page), the macOS menu bar shows the normal "Firefox, File, Edit, View, History, ......."

  • In the foreground window (with the target url content), the macOS menu bar ONLY shows "Firefox". There is no access to any of the Firefox dropdown menus.

Thanks,
Blake

(In reply to blake from comment #19)

I've noticed what might be another clue:

  • In the background window (with no content - blank page), the macOS menu bar shows the normal "Firefox, File, Edit, View, History, ......."

  • In the foreground window (with the target url content), the macOS menu bar ONLY shows "Firefox". There is no access to any of the Firefox dropdown menus.

Thanks,
Blake

This particular issue is tracked in 1603956.

See Also: → 1603956

Thanks Pascal, wewait for firefox75.

I've also noticed the Firefire menu bar is only showing "Firefox" tab, if you hover the menu bar near "Firefox" you get a empty drop down menu without a header where File, edit, view.... should be.

Attached image emptyMenuTabs
Duplicate of this bug: 1603425
You need to log in before you can comment on or make changes to this bug.