1775290 - (MacOS) Interface shifts when menubar is once used

Status: NEW

(Firefox :: Toolbars and Customization, defect, P3)

Description

[Intenditore]

Attachment: screenshot

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

Steps to reproduce:

Start FF, click on any menubar item

Actual results:

Interface shifts. Tabs go lower, window button - higher.

Expected results:

Nothing (in a matter of interface)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Markus Stange [:mstange]]

This is the second or third report we've seen about this bug. IIRC in the other reports, the issue was solved by resetting the profile.

Comment 3

[Zoë [:zoe]]

I'm affected by this bug too.

(In reply to Markus Stange [:mstange] from comment #2)

This is the second or third report we've seen about this bug. IIRC in the other reports, the issue was solved by resetting the profile.

If I understand correctly, "resetting the profile" is rather destructive because it will remove all extension and theme settings.

Is there any other workaround?

Comment 4

[Intenditore]

If I understand correctly, "resetting the profile" is rather destructive because it will remove all extension and theme settings.

Is there any other workaround?

Completely agree. I crafted my profile for years - wiping it isn't a solution. What's other option?

Comment 5

[Markus Stange [:mstange]]

The other option is for somebody to find the bug and fix it. I haven't done any work in this area recently but maybe I can point someone else in the right direction.

Since we haven't found any steps to reproduce yet, could I ask you to take some screenshots of the developer tools showing the XUL elements in question? First, follow these steps to enable the Browser Toolbox. Then, inspect the element that's located where the window buttons are, with the element picker tool as described on this documentation page. This should select an element called <hbox class="titlebar-buttonbox titlebar-color"> (if it doesn't, maybe you can find that element manually in the Inspector's tree view). Then, take a screenshot of the Inspector panel with that element selected, and the the CSS rules of it visible, and attach the screenshot to this bug.
Does the highlight rectangle which is drawn in the browser window when you hover the element in the Inspector match the location of the actual window buttons? I.e. is the highlight in the same wrong place, or is the highlight in the correct place but the window buttons in the wrong place?

Comment 6

[Intenditore]

Thank you for assistance! Here they are, nothing in CSS seems to change AT ALL.
Sorry it's all in foreign language, but it must be understandable I hope.
https://ibb.co/8rVDV03
https://ibb.co/XzrZcXq

But interestingly an element "spacer" appeared over tabs panel (it wasn't there before, I checked!).
https://ibb.co/6Y7x5wT
Instead it was behind
https://ibb.co/pPS5qXB

"CSS Changes" panes shows nothing

Comment 7

[Intenditore]

One more note - this problem doesn't arise in Safe more. Turning off all of the addons out of Safe mode doesn't take same effect though - problem persists.

Comment 8

[:Gijs (he/him)]

Can you please attach your raw about:support data? (go to about:support, then "copy raw data", then attach at https://bugzilla.mozilla.org/attachment.cgi?bugid=1775290&action=enter )

Comment 9

[Intenditore]

Attachment: about_support_int.rtf

Here it is

Comment 10

[Markus Stange [:mstange]]

(In reply to Intenditore from comment #6)

But interestingly an element "spacer" appeared over tabs panel (it wasn't there before, I checked!).
https://ibb.co/6Y7x5wT

In this screenshot I can see that your <toolbar id="toolbar-menubar"> now has autohide="true" set on it!

And if I set that attribute manually in my browser, I can reproduce the problem!

So then I guess the next question is, where does this autohide="true" come from? I can see it being set here, but that's in code which only runs when AppConstants.MENUBAR_CAN_AUTOHIDE is set, which it should never be on macOS.

Comment 11

[Markus Stange [:mstange]]

I'm going to mark this bug as a regression from bug 1752833, these reports have only appeared in the last 6 months, if I remember correctly.

Comment 12

[:Gijs (he/him)]

(In reply to Markus Stange [:mstange] from comment #10)

but that's in code which only runs when AppConstants.MENUBAR_CAN_AUTOHIDE is set, which it should never be on macOS.

If you evaluate that quoted code in the web console after opening the Firefox settings page, what is the return value? It sounds like it might be true, which as Markus said it really shouldn't be. Any idea why that might be the case? Any "interesting" custom JS you run as part of your Firefox install, for instance? Have you modified omni.ja ?

Comment 13

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

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

Comment 14

[Intenditore]

So then I guess the next question is, where does this autohide="true" come from? I can see it being set here, but that's in code which only runs when AppConstants.MENUBAR_CAN_AUTOHIDE is set, which it should never be on macOS.

I guess you've reminded me a very interesting thing regarding my FF profile! It originally was created on PC machine!

(In reply to :Gijs (he/him) from comment #12)

(In reply to Markus Stange [:mstange] from comment #10)

but that's in code which only runs when AppConstants.MENUBAR_CAN_AUTOHIDE is set, which it should never be on macOS.

If you evaluate that quoted code in the web console after opening the Firefox settings page, what is the return value? It sounds like it might be true, which as Markus said it really shouldn't be. Any idea why that might be the case? Any "interesting" custom JS you run as part of your Firefox install, for instance? Have you modified omni.ja ?

Value is FALSE
https://ibb.co/gmjqbSn

I have no custom js/css or anything else, only things I customized are some about:settings entries regarding telemetry and history preservation and a bunch of addons (none of which changes this behaviour as I just checked)

Comment 15

[:Gijs (he/him)]

(In reply to Intenditore from comment #14)

So then I guess the next question is, where does this autohide="true" come from? I can see it being set here, but that's in code which only runs when AppConstants.MENUBAR_CAN_AUTOHIDE is set, which it should never be on macOS.

I guess you've reminded me a very interesting thing regarding my FF profile! It originally was created on PC machine!

If you quit Firefox, then in your profile folder you rename xulstore.json and the xulstore folder, if it exists, to xulstore_old.json and xulstore_old, and reopen Firefox, is the problem gone?

Comment 16

[Intenditore]

If you quit Firefox, then in your profile folder you rename xulstore.json and the xulstore folder, if it exists, to xulstore_old.json and xulstore_old, and reopen Firefox, is the problem gone?

There's no such folder, but there is a file. Did what you've told to - the bug is gone! Awesome :)
I checked the contents of the file, it's messy, there are some websites, but nothing too personal, you can check it if you need https://drive.google.com/file/d/1fWpwMb7JpgK9m9KCrWO-WL9GKC5SJ1Kp/view?usp=sharing
The new one is much smaller, only two lines:

{"chrome://devtools/content/framework/browser-toolbox/window.html":{"devtools-toolbox-window":{"screenX":"308","screenY":"25","width":"1132","height":"872","sizemode":"normal"}}}

Comment 17

[:Gijs (he/him)]

Yeah, so, xulstore is used to persist temporary stuff like "was the window maximized and if not, where was it positioned the last time it was opened", for reuse the next time a given window is opened. This includes some attributes of toolbar state (e.g. "did the user have the bookmarks toolbar visible or not" and such like, though that has since moved to a preference anyway).

The culprit is this bit:

"toolbar-menubar":{"autohide":"true"}

which was meaningful on Windows (about whether or not the menubar was open), and isn't on macOS. We then included some CSS logic cross-platform, assuming the attribute would never be present on an OS where it would never be set, like macOS. So that's how this ended up broken.

I don't think adding logic back to make the CSS conditional is going to be super helpful here. It'll just be confusing.

The other issue is that realistically, there might be other stuff in that file that is at best unhelpful and at worst might cause bugs. I don't know that there's much we can really do about that. We could store platform information in the xulstore and just nuke all of it if the platform doesn't match the platform it's being run on. But that's not going to help people with older, copied xulstore when the next version of this problem arrives - it's a solution that'll stop people running into this a few years down the line. In the interim, I'm not sure that there's a generic fix we could create, and I'm not sure if the number of people running into this warrants creating a mac-specific 'remove this stray attribute' fix. Markus, wdyt?

Comment 18

[Intenditore]

Oh. Interestingly, all pinned tabs are now gone. I have very superficial knowledge of internal Firefox structure, but seems this file's "open" entries are responsible for that very purpose? It seemed to me it's all stored in sessions

Comment 19

[:Gijs (he/him)]

(In reply to Intenditore from comment #18)

Oh. Interestingly, all pinned tabs are now gone. I have very superficial knowledge of internal Firefox structure, but seems this file's "open" entries are responsible for that very purpose? It seemed to me it's all stored in sessions

The pinned tabs shouldn't be related to xulstore.json, they are kept in the sessionrestore files.

Comment 20

[Markus Stange [:mstange]]

Thanks for tracking this down!

(In reply to :Gijs (he/him) from comment #17)

The other issue is that realistically, there might be other stuff in that file that is at best unhelpful and at worst might cause bugs. I don't know that there's much we can really do about that. We could store platform information in the xulstore and just nuke all of it if the platform doesn't match the platform it's being run on. But that's not going to help people with older, copied xulstore when the next version of this problem arrives - it's a solution that'll stop people running into this a few years down the line. In the interim, I'm not sure that there's a generic fix we could create, and I'm not sure if the number of people running into this warrants creating a mac-specific 'remove this stray attribute' fix. Markus, wdyt?

Oh dear, that's tricky. Ideally, having a profile from a different OS should either work correctly or fail with an error, but now it mostly works and fails in obscure cases. And it's probably rare enough that it doesn't justify pouring effort into it.

Maybe we should just do nothing for now, and remember that whenever people complain about this odd space at the top of their window, they got a profile from a different OS and need to remove their xulstore folder and xulstore.json file.

Comment 21

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

:sclements, since you are the author of the regressor, bug 1752833, could you take a look?

For more information, please visit auto_nag documentation.

Comment 22

[Pascal Chevrel:pascalc (PTO until April 26)]

Sarah, you unset the regressing bug, does it mean that you think that we don't have the right regressor? Thanks

Comment 23

[Pascal Chevrel:pascalc (PTO until April 26)]

Markus, do we have a bug where we intend to have a more robust and portable caching system for xulstore? People switching OSes seems like a not so uncommon scenario to me :)

Comment 24

[Sarah Clements [:sclements]]

(In reply to Pascal Chevrel:pascalc from comment #22)

Sarah, you unset the regressing bug, does it mean that you think that we don't have the right regressor? Thanks

Looking at comments 17 and 20, it doesn't look like there's a regression per say. Just some fallout/tricky nuances of loading a profile from a different OS.

Comment 25

[:Gijs (he/him)]

(In reply to Pascal Chevrel:pascalc from comment #23)

Markus, do we have a bug where we intend to have a more robust and portable caching system for xulstore? People switching OSes seems like a not so uncommon scenario to me :)

People switching OSes, maybe or maybe not (I actually think not!), but people manually finding their Firefox profile folder and copying over all the raw data (rather than using sync or export+import of bookmarks/passwords, or a new migrator that we are working on as a student project), seems uncommon. There are other things that are likely to break, e.g. any preferences stored that have file paths which may not exist or even be completely invalid on a different OS.

I'm really not sure it's worth spending a lot of time on this.

Comment 26

[Markus Stange [:mstange]]

Maybe we could have a documentation page that says "Don't copy profiles between different operating systems".

Comment 28

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

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1796931: S3

:Gijs, could you consider increasing the severity of this bug to S3?

For more information, please visit auto_nag documentation.

Comment 29

[:Gijs (he/him)]

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

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1796931: S3

:Gijs, could you consider increasing the severity of this bug to S3

Considered, but sticking with S4.