Reproducible: always Steps To Reproduce: 1. open page Actual Results Toolbutton jumps to left See attached screen cast.

Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=76a7ead2334c65a6420038919047dce69d040166&tochange=5f580744fe7ae5350f6278ce70749a5696f8d4a5 Regresed by: 5f580744fe7a Dão Gottwald — Bug 1396624 - Hide URL bar elements and the stop button with display:none instead of visibility:collapse to prevent the icons from being loaded needlessly. r=johannh

(In reply to Dão Gottwald [::dao] from comment #2) > Created attachment 8905056 [details] > Bug 1397285 - Set standard toolbarbutton-1 icon size as width rather than > max-width to reserve space for icons while they're loading. Is this patch also fixing bug 1394914?

(In reply to Florian Quèze [:florian] [:flo] from comment #3) > (In reply to Dão Gottwald [::dao] from comment #2) > > Created attachment 8905056 [details] > > Bug 1397285 - Set standard toolbarbutton-1 icon size as width rather than > > max-width to reserve space for icons while they're loading. > > Is this patch also fixing bug 1394914? It seems like it might fix that, but I don't know how exactly the sidebar button is special, i.e. with how much of a delay it's added (and why). If we first paint without the <toolbarbutton> being in the toolbar and then the button gets added (!= the icon gets loaded), then there's no way this will fix bug 1394914.

(In reply to Dão Gottwald [::dao] from comment #4) > (In reply to Florian Quèze [:florian] [:flo] from comment #3) > > (In reply to Dão Gottwald [::dao] from comment #2) > > > Created attachment 8905056 [details] > > > Bug 1397285 - Set standard toolbarbutton-1 icon size as width rather than > > > max-width to reserve space for icons while they're loading. > > > > Is this patch also fixing bug 1394914? > > It seems like it might fix that, but I don't know how exactly the sidebar > button is special, i.e. with how much of a delay it's added (and why). If we > first paint without the <toolbarbutton> being in the toolbar and then the > button gets added (!= the icon gets loaded), then there's no way this will > fix bug 1394914. I can only reproduce it on the first window, not on the next ones, so I think it's only the icon's load time that causes the flicker... for me. If others are seeing it on all new windows, there's an additional issue to fix there.

Comment on attachment 8905056 [details] Bug 1397285 - Set standard toolbarbutton-1 icon size as width rather than max-width to reserve space for icons while they're loading. https://reviewboard.mozilla.org/r/176862/#review181890 Works for me. :)

Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/16290ce48f84 Set standard toolbarbutton-1 icon size as width rather than max-width to reserve space for icons while they're loading. r=johannh

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20170925100307 This issue has been verified on latest Firefox Nightly Build ID: 20170925100307 on Windows 8.1 x64, Mac OS 10.12 and Ubuntu 14.04 and I cannot reproduce it. Now, when opening a bookmarked webpage or any other webpages the URL bar and Home button do not jump to left.

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170928180207 This issue has been verified on latest Firefox Beta 57.0b4 on Windows 8.1 x64, Mac OS 10.12 and Ubuntu 14.04 and I cannot reproduce it.