1588953 - (gigabar) New "expanded" address bar triples in size

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: Screen Shot 2019-10-15 at 4.56.16 PM.png

Unfortunately I don't have an STR. Nightly 71.0a1 (2019-10-15).

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Oh I think I can reliable reproduce this one now:

• Copy a long URL or text.
• Command-N
• Command-V

Timing may be important.

Comment 2

[Lina Butler [:lina]]

Same! I can repro if I press Cmd+N to open a new window, then Cmd+V to paste right away, before the new window finishes loading. When the window does load, it'll have a triple-height awesomebar with whatever I pasted. I have an older MBP with lots of tabs open and a Firefox build going, which might make it easier to trigger. No errors in the browser console.

Comment 3

[Dão Gottwald [:dao]]

I can reproduce this on Windows but not on Linux.

Comment 4

[Harry Twyford]

It appears this was caused by bug 1580248. That patch added these calculations for --urlbar-height and --urlbar-container-height: https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#1116-1123

The inspector suggests that these are getting set to very high values (100px+) if _updateLayoutBreakoutDimensions is called while a new window is initializing, which is causing the gigantic megabar.

Comment 5

[Dão Gottwald [:dao]]

(In reply to Harry Twyford [:harry] from comment #4)

It appears this was caused by bug 1580248.

Maybe. If that's indeed the regression range, then that's not very useful I'm afraid. I was hoping something broke in the meantime causing --urlbar-height to be off-base.

Comment 6

[Dão Gottwald [:dao]]

I'll try to figure out a fix for this anyway.

Comment 7

[Alin Ilea, Desktop QA]

Hi,

Since the bug is not reproducible all the time it is very difficult to find a precise regression range. However I found a regression range that looks more appropriate. Here is the pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4eca2af6d2d5a850c7f61e27eaf052936fee0b2f&tochange=cc25750fd9e8b0015f6a693f87d87b2fc3e0a29d

Please see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1577472

Thanks.

Comment 8

[Dão Gottwald [:dao]]

Thanks, that range seems a bit more useful.

Comment 9

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [::dao] from comment #3)

I can reproduce this on Windows but not on Linux.

Also, I can only reproduce this with PGO builds on Windows.

Comment 14

[giul.mus]

Chiming in to mention that I could also reproduce it in Linux (see bug 1591169), so this is not Windows-specific.

Comment 15

[Dão Gottwald [:dao]]

(In reply to Harry Twyford [:harry] [OoO/PTO Oct 21 - Nov 1] from comment #4)

It appears this was caused by bug 1580248. That patch added these calculations for --urlbar-height and --urlbar-container-height: https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#1116-1123

The inspector suggests that these are getting set to very high values (100px+) if _updateLayoutBreakoutDimensions is called while a new window is initializing, which is causing the gigantic megabar.

I've been trying to figure out what element in the toolbar is enlarging the toolbar in this way, but so far without luck. I'm wondering, could this be related to bug 1592054?

Comment 16

[Brian Grinstead [:bgrins]]

(In reply to Dão Gottwald [::dao] from comment #15)

(In reply to Harry Twyford [:harry] [OoO/PTO Oct 21 - Nov 1] from comment #4)

It appears this was caused by bug 1580248. That patch added these calculations for --urlbar-height and --urlbar-container-height: https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#1116-1123

The inspector suggests that these are getting set to very high values (100px+) if _updateLayoutBreakoutDimensions is called while a new window is initializing, which is causing the gigantic megabar.

I've been trying to figure out what element in the toolbar is enlarging the toolbar in this way, but so far without luck. I'm wondering, could this be related to bug 1592054?

I doubt it, but if you can reproduce this problem reliably you could check with that patch. The main visual effect that has is not applying attributes onto child nodes immediately - and I don't think any of those attributes change the height. Likewise if I manually delete the tab-stack node (simulating the content not being appended) it doesn't seem to change the height of the tab.

Comment 17

[Brian Grinstead [:bgrins]]

If you change _updateLayoutBreakoutDimensions to use getBoundingClientRect instead of getBoundsWithoutFlushing does it fix the problem?

Comment 18

[Dão Gottwald [:dao]]

(In reply to Brian Grinstead [:bgrins] from comment #16)

(In reply to Dão Gottwald [::dao] from comment #15)

(In reply to Harry Twyford [:harry] [OoO/PTO Oct 21 - Nov 1] from comment #4)

It appears this was caused by bug 1580248. That patch added these calculations for --urlbar-height and --urlbar-container-height: https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#1116-1123

The inspector suggests that these are getting set to very high values (100px+) if _updateLayoutBreakoutDimensions is called while a new window is initializing, which is causing the gigantic megabar.

I've been trying to figure out what element in the toolbar is enlarging the toolbar in this way, but so far without luck. I'm wondering, could this be related to bug 1592054?

I doubt it, but if you can reproduce this problem reliably you could check with that patch.

No, I'm sure that patch wouldn't help here, since that bug is about the tab bar and this one is happening in the navigation toolbar. I was rather wondering if a similar issue could exist here since various bindings used in this toolbar were converted to custom elements as well.

Comment 19

[Brian Grinstead [:bgrins]]

Attachment: paused-in-bad-case.png

I paused when getBoundsWithoutFlushing(this.textbox.parentNode).height > 40) and then opened browser toolbox in a debug build and continually opened new windows / pasted contents until I triggered it. Here's what I see.

It's a bit hard to dig in because once I switch to the new window in the Inspector things snap into the "normal" broken case but it seems like the orientation is wrong inside the urlbar and/or the search icons aren't being hidden.

Comment 20

[Brian Grinstead [:bgrins]]

(In reply to Dão Gottwald [::dao] from comment #18)

(In reply to Brian Grinstead [:bgrins] from comment #16)

(In reply to Dão Gottwald [::dao] from comment #15)

(In reply to Harry Twyford [:harry] [OoO/PTO Oct 21 - Nov 1] from comment #4)

It appears this was caused by bug 1580248. That patch added these calculations for --urlbar-height and --urlbar-container-height: https://searchfox.org/mozilla-central/source/browser/components/urlbar/UrlbarInput.jsm#1116-1123

The inspector suggests that these are getting set to very high values (100px+) if _updateLayoutBreakoutDimensions is called while a new window is initializing, which is causing the gigantic megabar.

I've been trying to figure out what element in the toolbar is enlarging the toolbar in this way, but so far without luck. I'm wondering, could this be related to bug 1592054?

I doubt it, but if you can reproduce this problem reliably you could check with that patch.

No, I'm sure that patch wouldn't help here, since that bug is about the tab bar and this one is happening in the navigation toolbar. I was rather wondering if a similar issue could exist here since various bindings used in this toolbar were converted to custom elements as well.

I don't see any Custom Elements that inject their own content / do attribute inheritance when looking through the internals of the quantumbar. And the screenshot in Comment 19 makes me think that quantumbar itself is the thing expanding the height of the toolbar, since there appear to be other visual/layout issues with it in that state.

Comment 21

[Dão Gottwald [:dao]]

(In reply to Brian Grinstead [:bgrins] from comment #20)

I don't see any Custom Elements that inject their own content / do attribute inheritance when looking through the internals of the quantumbar. And the screenshot in Comment 19 makes me think that quantumbar itself is the thing expanding the height of the toolbar, since there appear to be other visual/layout issues with it in that state.

It looks like the one-off search buttons are displayed inside the urlbar. This clearly shouldn't happen...

Comment 23

[Dão Gottwald [:dao]]

Attachment: Bug 1588953 - Don't let UrlbarView::_openPanel display results before UrlbarInput::_updateLayoutBreakoutDimensions has finished. r=mak

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b3ec0c179174
Don't let UrlbarView::_openPanel display results before UrlbarInput::_updateLayoutBreakoutDimensions has finished. r=mak

Comment 25

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/b3ec0c179174

Comment 26

[Alin Ilea, Desktop QA]

Verified - fixed on latest Nightly 72.0a1 (Build id: 20191030215116) with browser.urlbar.megabar changed to true, by default in Nightly 72 the megabar feature is off (moved to Fx73).

Comment 27

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b3ec0c179174