1527577 - Toolbar sometimes opens with too large address bar at startup, with all toolbar buttons in "overflow" region

Status: RESOLVED WORKSFORME

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

Description

[Sergio Callegari]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Starting firefox on Kubuntu linux, the program sometimes opens up with the toolbar incorrectly displayed.

Actual results:

The toolbar often opens with an address bar that takes up all the availble horizontal space (does not rescale). As a consequence, all the buttons are not shown (they only appear when pressing the overflow button).

When the toolbar opens in this way, clicking on "customize" and then immediately exiting the customization brings back the toolbar to its correct rendering, with a shorter address bar that allows enough space to its right for the buttons.

Expected results:

The toolbar should always appear correctly, and given that there is enough space, the buttons should be shown.

Comment 1

[Sergio Callegari]

Attachment: firefox-wrong-toolbar.png

This is the toolbar as it almost always opens.

Comment 2

[Sergio Callegari]

Attachment: firefox-correct-toolbar.png

This is the toolbar as it should open

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Hi Sergio, the next time this happens can you open the Browser Console and see if there are any errors in there? You can open it by pressing Ctrl+Shift+J.

Also, about how often does this happen? If it happens somewhat frequently, could you use mozregression[1] to see when this started happening?

[1] https://mozilla.github.io/mozregression/

Comment 4

[Mike Conley (:mconley) (:⚙️)]

I'm tempted to move this to Widget :: Gtk for now. If I had to guess, I'd say that the initial window is sometimes reported as being too small, we're overflowing, which stashes all of the toolbar items into the overflow... and then the window assumes it's final size, and we don't receive underflow.

So I suspect this might have to do with some special-ness on how we handle window resize events with the Gtk widget layer.

Comment 5

[Sergio Callegari]

Here is the output from the browser console, when I see the issue.

Could not read chrome manifest 'file:///usr/lib/firefox/chrome.manifest'.
OpenGL compositor Initialized Succesfully.
Version: 3.0 Mesa 18.3.3 - padoka PPA
Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Haswell Mobile
FBO Texture Target: TEXTURE_2D
Error: listener not re-registered
ExtensionCommon.jsm:2158:24
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”). background.js:3764:15
Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt” id=“key_toggleReaderMode” browser.xul
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xul
OpenGL compositor Initialized Succesfully.
Version: 3.0 Mesa 18.3.3 - padoka PPA
Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Haswell Mobile
FBO Texture Target: TEXTURE_2D

The issue happens about 50% of the times.

As additional points that I was forgetting:

• when I see the issue, if I try to reduce the window size and then to enlarge it again, the overflow does not change. Only opening and reclosing the customize pane restores the correct toolbar.

• I am on KDE, that may implement some own logic on how the window is maximized at startup.

Comment 6

[Sergio Callegari]

I have made some more tests and I now have a strong feeling that this issue is KDE related, since after some tests with the KDE maximize preset I am not getting the wrong behaviour any more.

My theory is the following:

• KDE remembers if some application window is to start maximized (this is in fact what I have for firefox)
• At the same time, KDE remembers the unmaximized position an size of the windows by application
• When an application is started KDE first opens it at its saved unmaximized size and then if the application is expected to be maximized immediately maximizes it
• The above situation causes a race in firefox. If firefox at startup sees the window in its unmaximized size and the latter is small, then all buttons are pushed to the overflow button and when the window is maximized they stay there. Conversely, if KDE is faster and maximizes the window before firefox checks it at startup, then firefox sees a large window and does not push the buttons to the overflow button.

My theory is justified by the fact that in order to "fix" the issue, I have unmaximized firefox and enlarged the unmaximized window, then closed firefox (so as to make KDE remember this status), then restarted firefox, maximized its window and closed it again.

I think that firefox should check when its window size is changed (specifically by maximization) and if so it should check if some items can be moved from the toolbar to the overflow button or viceversa. Otherwise it should wait a bit longer to measure its window size at startup in order to avoid racing with the window manager.

Comment 7

[Daniel Bodea [:danibodea]]

Jim, what do you think about this bug? Should it be closed or does it need some more investigation?

Comment 8

[Jim Mathies [:jimm]]

Sounds like a bug we'd like to get to at some point.

Comment 9

[Daniel Bodea [:danibodea]]

Considering the "regressionwindow-wanted" tag, I would like to try to find it's regressor, but I am lacking some steps to reproduce. I could not reproduce it with the information provided so far.

Please NI me if and when testing is needed.

Comment 10

[Dão Gottwald [:dao]]

I expect bug 1580538 fixed this.