User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110925 Firefox/9.0a1 Build ID: 20110925030856 Steps to reproduce: navigation toolbar's height is increases +1px on SSL page. This bug occurs after bug 684450 is fixed. Actual results: 1. visit non-SSL page. 2. visit SSL page.

This bug is occurring on Firefox Nightly (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110925 Firefox/9.0a1) and hardware acceleration is enabled.

WFM.

(In reply to Peter Henkel [:Terepin] from comment #2) > WFM. I am not seeing this either.

(In reply to saneyuki_s from comment #1) > This bug is occurring on Firefox Nightly (Mozilla/5.0 (Windows NT 6.1; > WOW64; rv:9.0a1) Gecko/20110925 Firefox/9.0a1) and hardware acceleration is > enabled. Do you have any add-ons installed that modify your toolbar?

(In reply to Margaret Leibovic [:margaret] from comment #4) > Do you have any add-ons installed that modify your toolbar? No. New & clean profile reproduces this bug.

Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111001 Firefox/10.0a1 ID:20111001030845 http://forums.mozillazine.org/viewtopic.php?p=11314439#p11314439 OS (Japanese version)/Japanese Font issue ?

(In reply to pal-moz from comment #6) > OS (Japanese version)/Japanese Font issue ? I don't conclude it. I reproduce this bug on Firefox whose locale is en-US, and I use Windows 7 x64 (Japanese).

(In reply to pal-moz from comment #6) > OS (Japanese version)/Japanese Font issue ? It occurs also in European Fonts. Loot at last Duplicate (693764).

I am also seeing this in Win7 SP1 64bit English Version with an English Firefox. My language settings in Windows are: Format: Chinese (Traditional, Hong Kong S.A.R.) Location: Hong Kong S.A.R. Current language for non-Unicode programs: Chinese (Traditional, Hong Kong S.A.R.)

Reproducible on Windows 7 32bit English language version Settings in Windows: Format: Polish

Finally found the steps to 100% bug reproduce on my computers: Bug occur only when the Windows 7 system default size of text settings is changed from normal 100% to Medium (125%) or Larger (150%) in display control panel (check the attachement for settings picture) Changing the: - format - location - system locale (current language for non-Unicode programs) from Polish to UK changes nothing to bug behaviour Bug also occur with (1/1 Direct3D 10) and without enabled hardware acceleration Can also confirm regression range from comment 1: Last good nightly: 2011-09-24 First bad nightly: 2011-09-25 Pushlog: http://hg.mozilla.org/mozilla-central/pushlog?fromchange=c71229984353&tochange=afe75f8431ad

(In reply to kolubinowicki from comment #12) > Finally found the steps to 100% bug reproduce on my computers: > > Bug occur only when the Windows 7 system default size of text settings is > changed from normal 100% to Medium (125%) or Larger (150%) in display > control panel (check the attachement for settings picture) not true. happen with default (100%) setting.

In reply to comment 13 >not true. happen with default (100%) setting. On my configuration I can reproduce in 100% time (check the video in attachement) maybe there is some other additional bug triggers?

Confirmed on Firefox9.0.1 to 12.0a1. In case of system font using Meiryo (メイリオ) which is default font for Aero/Aero Basic windows7 style (Japanese edition) WORKAROUND(use default font for Classic windows7 style): #identity-box label { font-family: "MS UI Gothic"!important; }

Regression window(m-c), Works: http://hg.mozilla.org/mozilla-central/rev/fecae145d884 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110924 Firefox/9.0a1 ID:20110924032918 Fails: http://hg.mozilla.org/mozilla-central/rev/95df67109868 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110924 Firefox/9.0a1 ID:20110924082020 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fecae145d884&tochange=95df67109868 Regression window(m-i), Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/d5727cb7221b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110923 Firefox/9.0a1 ID:20110923215818 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/8f064c1c1d40 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110924 Firefox/9.0a1 ID:20110924050718 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d5727cb7221b&tochange=8f064c1c1d40 Suspected bug: Bug 684450 - Remove stop/go/reload button affordance and streamline other location bar icons

WORKAROUND2(preserve font-family): #page-proxy-stack { margin-top: 1px !important; }

I observed that bug in FF8 too. I'm using French Win 7 with Aero, default font type, display at 125% (1080p laptop screen), HWA enabled in FF.

IMHO the new bug title is incorrect. I have HWA disabled and only run into this bug when I increase system font size to 125%. See also comment #12. Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:12.0a1) Gecko/20111223 Firefox/12.0a1

This inserts empty label element for reserving enough height for urlbar. I'm not sure whether this is the best approach. Testing on tryserver now. https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=27ba095d2c1d

The tryserver builds will be here: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/masayuki@d-toybox.com-27ba095d2c1d/

Hardware acceleration shouldn't cause this bug. It really depends on the font and the result of rendering (DirectWrite and GDI are using different logic for rendering fonts though).

Comment on attachment 593775 [details] [diff] [review] Quick fix I have no idea to test this patch.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #24) The patch from tryserver build works ok (https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=27ba095d2c1d), the toolbar don't change the position when switching tabs, but there is one additional glitch: The height of search bar is not the same size as adress bar. (Please check the video in attachement and the screenshot)

kolubinowicki: Thank you for testing. Yes, it is, but it's a problem of the design of the identify button. Even though we fix add similar hack to the searchbar, another similar toolbar textbox which is added by addon can have same problem.

Okay, the cause of making higher URL bar is, the #identity-box has unnecessary padding-top and padding-bottom. But I still think that the empty <label> should be in it for spacer for preventing the dynamic height change.

Comment on attachment 594017 [details] [diff] [review] Patch (removing unnecessary padding of #identity-box Oh, this change causes a regression.

Hmm, even when I applied only the second patch to m-c, window.innerHeight and window.innerWidth becomes 4px smaller on tryserver. https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=ae6d738e0f10 > 74721 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | Checking doc height - got 296, expected 300 > 74722 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | image width - got 394, expected 378 > 74723 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | image height - got 296, expected 284 > 74732 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | image width - got 394, expected 378 > 74733 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | image height - got 296, expected 284 > 74740 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | Checking scrollTop - got 304, expected 300 > 74742 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | image width - got 394, expected 378 > 74743 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/document/test/test_bug369370.html | image height - got 296, expected 284 > 364 ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug344861.html | window.open has correct height dimensions - got 196, expected 200 > 514 ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug637644.html | Popups should look identical I cannot understand the reason. When I test docshell/test/test_bug344861.html, the most simple test, on my system (Win7, Aero with Meiryo), the result becomes innerHeight=198 and innerWidth=196. However, when I reload the test, all of tests in it pass. I think that there is a hidden bug for sizing window, but I don't familiar with docshell. bz: Any idea? dao: Could you review the first patch? Anyway, changing the urlbar height per tab/page is very ugly.

The way the height and width options to window.open are handled is that we open a browser window, wait for the XUL to load, reflow it, measure the difference between the innerWidth and outerWidth (and similarly for height), add that difference to the requested width/height and then resize the toplevel window to the resulting size. When you say "second patch", do you mean attachment 594017 [details] [diff] [review]? Is it possible that for some reasons that style is not applied at window load time?

(In reply to Boris Zbarsky (:bz) from comment #31) > The way the height and width options to window.open are handled is that we > open a browser window, wait for the XUL to load, reflow it, measure the > difference between the innerWidth and outerWidth (and similarly for height), > add that difference to the requested width/height and then resize the > toplevel window to the resulting size. Thanks for your explanation. > When you say "second patch", do you mean attachment 594017 [details] [diff] [review] > [review]? Yes, I do. > Is it possible that for some reasons that style is not applied at window > load time? I have no idea because when I reload the test file, the computed size is correct. And also, when I run the debug build normally and test following URL, the size is correct too. So, only when the first time of the test, it fails...

That's... really odd. This test is running (and failing) partway through the test suite, right? So it's not like the browser UI is somehow not fully loaded....

(In reply to Boris Zbarsky (:bz) from comment #33) > That's... really odd. This test is running (and failing) partway through > the test suite, right? Right, it's failed on tryserver too. But I tried to reload it when I run only the test from commandline. > So it's not like the browser UI is somehow not fully > loaded.... And the UI is only the URL bar because "toolbar" isn't "yes" of window.open(). So, it opens different UI from the parent window which has the test harness.

That shouldn't really matter... You can reliably reproduce this when you run just that one test, as long as you only run it once after startup?

Hmm... * FAILED when I use > TEST_PATH=docshell/test/test_bug344861.html build/pymake/make.py -C ../firefox-debug-build mochitest-plain * SUCCEEDED when I use > TEST_PATH=docshell/test build/pymake/make.py -C ../firefox-debug-build mochitest-plain * SUCCEEDED when I use > python ../firefox-debug-build/_tests/testing/mochitest/runtests.py and wait until finish loading the harness and click the link for test_bug344861.html

Related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=549898 Also the following code in userChrome.css or Stylish addon, could work as a temporary bug work-around: .verifiedDomain, .verifiedIdentity { padding: 0px 2px !important; }

after Bug 742419 fix, toolbar height is same. but locationbar (input area) height is 1pix higher when EV-SSL.

(In reply to pal-moz from comment #38) > after Bug 742419 fix, toolbar height is same. > but locationbar (input area) height is 1pix higher when EV-SSL. Confirmed on Win7 x64 with 125% font size (Screen settings in Windows).

Does this still happen after bug 747608?

In my case, it doesn't happen since changing to "white background and no favico" in identity-box.

seems to be fine now.

(In reply to Dão Gottwald [:dao] from comment #40) > Does this still happen after bug 747608? I tried with the latest Nightly (fresh profile), it's not fixed in all cases. HTTPS websites with Extended Validation still have the extra 1 px in the location bar.

(In reply to Loic from comment #43) > Created attachment 641842 [details] > Snapshot after bug 747608 landed > > (In reply to Dão Gottwald [:dao] from comment #40) > > Does this still happen after bug 747608? > > I tried with the latest Nightly (fresh profile), it's not fixed in all cases. > HTTPS websites with Extended Validation still have the extra 1 px in the > location bar. I can confirm that too. Now, when we don't have borders in buttons, it can be easily overlooked...

Comment on attachment 593775 [details] [diff] [review] Quick fix It seems like this will permanently (rather than only for EV SSL) increase the location bar's height, making it not match the search bar.