1800550 - Windows and other items disappear from Window menu

Status: RESOLVED DUPLICATE of bug 1807697

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

Description

[Sam Johnson]

Attachment: example2.png

I've been noticing some peculiar behavior with the Window menu today, and I am not quite certain what is causing this behavior.

I have two windows open, one is a normal browser window, and another is a popup window opened via JavaScript with no tabbar.

When opening the Window menu, I am intermittently seeing one of four behaviors:

1. The menu opens with the full complement of menu options and windows listed
2. The menu opens, but the only menu items are "Minimize" and "Zoom"
3. The menu opens, but the section with the options to "Move window to the left side of the screen" is missing, as well as the section listing the open windows, but the "Move window to (display name here)" section is present, as is Minimize and Zoom.
4. Same as number 3, but with the windows listed.

I am attaching screenshots of each scenario above. Note that between screenshots, all I did was open/close menus and switch tabs.

Comment 1

[Sam Johnson]

Attachment: example3.png

Comment 2

[Sam Johnson]

Attachment: example4.png

Comment 3

[Sam Johnson]

Attachment: example1.png

Comment 4

[Sam Johnson]

I forgot to mention: All screenshots are from Nightly build 20221114085151.

Comment 5

[Haik Aftandilian [:haik]]

This is likely to be related to the changes made recently on bug 1642138.

Comment 6

[Stephen A Pohl [:spohl]]

Could you please clarify a few things:

1. How do you open the popup window with JavaScript? Are you doing this from the browser console or can you provide a sample .html file to ensure that we're looking at the same thing?
2. Can you clarify which one of the windows is active for each screenshot that you posted?
3. Does the Window menu only show incorrect menu items if the popup window is focused? Or do all windows reproduce this?

Comment 7

[Sam Johnson]

Sorry, I suppose mentioning a popup window confused things. I have been seeing this issue almost daily since the report, and it occurs even with a single browser window. This doesn't reproduce 100% of the time, but here is the order of operations I consistently observe:

1. Be working in application on monitor 1.
2. Focus the Firefox window on monitor 2. Then, open the Window menu.
3. Example 2 above is observed.
4. Click in the Firefox window to close the menu, then open the Window menu again.
5. Example 3 above is observed.
6. Click in the Firefox window to close the menu
7. Switch to another tab in the same window, then open the Window menu again.
8. Now the window is listed as in examples 1 and 4.

Comment 8

[Stephen A Pohl [:spohl]]

What version of macOS is this on?
How are you starting Firefox?
Do you have "restore tabs after restart" enabled?

Comment 9

[Sam Johnson]

This is on macOS 13.0.1. In practice the only way I ever start Firefox is via the updater, which does restore my tabs (I run Nightly).

Comment 10

[Stephen A Pohl [:spohl]]

(In reply to Sam Johnson from comment #9)

This is on macOS 13.0.1. In practice the only way I ever start Firefox is via the updater, which does restore my tabs (I run Nightly).

Does this reproduce if you close Nightly and start it manually?

Comment 11

[Sam Johnson]

(In reply to Stephen A Pohl [:spohl] from comment #10)

(In reply to Sam Johnson from comment #9)

This is on macOS 13.0.1. In practice the only way I ever start Firefox is via the updater, which does restore my tabs (I run Nightly).

Does this reproduce if you close Nightly and start it manually?

Sorry for the delay, but I can confirm I encounter the issue even after starting Nightly manually (this morning I performed a manual close / open after verifying I was on the latest build).

Comment 12

[Sam Johnson]

Here is what I observed so far today:

1. After verifying my Nightly was completely up to date, I closed it, then opened it via my dock.
2. I opened the Window menu after opening Nightly and confirmed that all menu items were present (example 1 above).
3. Later in the day, I checked the Window menu again, and only saw Minimize and Zoom (example 2 above)
4. Then I closed and reopened the Window menu again, and saw example 3
5. I switched tabs, opened the Window menu again, and saw example 4.

At this point, my Nightly is still in the 'example 4' state. The lost menu items that only exist in example 1 never returned.

Comment 13

[Sam Johnson]

If I open a second browser window, the lost items from example 1 return. If I close that second browser window and return to the original window, the items disappear again.

Comment 14

[Stephen A Pohl [:spohl]]

Could you tell me more about the number of external screens that you have, and how they are arranged relative to (presumably) your MacBook screen? Also, what is your setting under System Settings > Desktop & Dock > Mission Control > Displays have separate Spaces? Are there any other settings that you might have changed from their default values?

Comment 15

[Sam Johnson]

Sure:

• I have three total displays, including the internal MacBook display. They are arranged as follows (from left to right): Display | Display (set as primary) | MacBook. Both external displays are of the same model.
• The MacBook display is retina; the others are 1080p.
• Firefox usually lives on the leftmost display (not the primary), though I do sometimes drag a window across displays. I open it directly on the leftmost display.
• 'Displays have separate Spaces' is enabled

I can't think of any other obvious settings I've changed (and this is a pretty recent install from May, so hopefully I haven't forgotten anything).

Anecdotally, I haven't encountered this issue on my Mac Studio, also on 13.0.1. It also has three displays, none retina, the only difference I can think of is that Nightly is almost always on the primary display on that machine (and that's where I open it on). However, I don't use the Window menu nearly as often on this machine (for whatever reason, I lose windows a lot on the other machine!), so it could simply be due to lack of usage.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1642138

Comment 17

[Stephen A Pohl [:spohl]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #16)

Set release status flags based on info from the regressing bug 1642138

Regarding tracking this issue for a specific release: This is an intermittent regression that does not appear to be widespread at this time. As discovered in bug 1806451, this issue may be triggered by opening certain windows such as the global WebRTC indicator. However, this issue alone does not warrant a backout of bug 1642138. I will be looking into this issue next.

Comment 18

[Stephen A Pohl [:spohl]]

Sam, I have been able to track down one reason related to WebRTC why the Window menu might stop behaving as expected. However, I can't tell for sure if this is the same underlying issue that you have experienced. Would you be able to test this build and let me know if you're still able to reproduce the issue? Thanks!

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PytFc9mkQyqGJ6AzwfQ2ig/runs/0/artifacts/public/build/target.dmg

Comment 19

[Sam Johnson]

@spohl sorry for the delay, I was away from the affected machine on break. I can confirm that the issue still occurs in the latest Nightly with the fix from bug 1806451. I'll report back on the linked build (may be a few more days before I can confirm results). Thanks!

Comment 20

[Stephen A Pohl [:spohl]]

Attachment: Bug 1800550: Move the 'Tabs sharing devices' menu item for WebRTC from the Window menu to the Tools menu on macOS. r=Gijs

Comment 21

[Phabricator Automation]

Comment on attachment 9309911 [details]
Bug 1800550: Move the 'Tabs sharing devices' menu item for WebRTC from the Window menu to the Tools menu on macOS. r=Gijs

Revision D165563 was moved to bug 1807697. Setting attachment 9309911 [details] to obsolete.

Comment 22

[Sam Johnson]

@spohl Good news! I am not able to reproduce the issue in the linked build with the same usage patterns. I am a very heavy WebRTC user, so it does seem like that was causing it.

Comment 23

[Stephen A Pohl [:spohl]]

Great, thank you for confirming! I have just queued the patch for landing in bug 1807697. I'm going to mark this bug as a duplicate of bug 1807697 since there is more technical detail around the fix there.

Comment 24

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Bug 1807697 has been uplifted for 109.0b8.

Comment 25

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Bug 1807697 has been uplifted for 108.0.2 as well