Closed Bug 1588953 (gigabar) Opened 1 year ago Closed 1 year ago

New "expanded" address bar triples in size

Categories

(Firefox :: Address Bar, defect, P2)

Desktop
All
defect
Points:
3

Tracking

()

VERIFIED FIXED
Firefox 72
Iteration:
72.1 - Oct 21 - Nov 3
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- disabled
firefox72 --- verified

People

(Reporter: st3fan, Assigned: dao)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

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

Oh I think I can reliable reproduce this one now:

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

Timing may be important.

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.

Points: --- → 3
Priority: -- → P2

I can reproduce this on Windows but not on Linux.

OS: macOS → All

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.

(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.

Keywords: regression

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

Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Iteration: --- → 71.4 - Oct 14 - 20
Iteration: 71.4 - Oct 14 - 20 → 72.1 - Oct 21 - Nov 3

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.

Has Regression Range: --- → yes
Flags: needinfo?(dao+bmo)

Thanks, that range seems a bit more useful.

Flags: needinfo?(dao+bmo)
Keywords: regression
Regressed by: 1577472

(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.

Duplicate of this bug: 1586553
Duplicate of this bug: 1586570
Duplicate of this bug: 1591169
Duplicate of this bug: 1591548

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

(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?

Flags: needinfo?(bgrinstead)

(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.

Flags: needinfo?(bgrinstead)

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

(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.

Attached image 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.

(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.

(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...

Duplicate of this bug: 1592406
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b3ec0c179174
Don't let UrlbarView::_openPanel display results before UrlbarInput::_updateLayoutBreakoutDimensions has finished. r=mak
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72

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).

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.