689079 - Location bar height increases by 1px on pages with EV SSL

Status: NEW

(Firefox :: Theme, defect)

Description

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

Attachment: screenshot

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.

Comment 1

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

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.

Comment 2

[Peter Henkel [:Terepin]]

WFM.

Comment 3

[Stephen Horlander [:shorlander]]

(In reply to Peter Henkel [:Terepin] from comment #2)
> WFM.

I am not seeing this either.

Comment 4

[:Margaret Leibovic]

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

Comment 5

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

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

Comment 6

[pal-moz]

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 ?

Comment 8

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

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

Comment 9

[Michał]

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

Comment 10

[Fanolian]

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

Comment 11

[kolubinowicki]

Attachment: Video with bug behaviour

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

Comment 12

[kolubinowicki]

Attachment: Windows 7 system settings that cause the bug occurence

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

Comment 13

[pal-moz]

Attachment: screenshot

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

Comment 14

[kolubinowicki]

Attachment: Video with bug behaviour, different Windows 7 settings

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?

Comment 15

[Alice0775 White]

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;
}

Comment 16

[Alice0775 White]

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

Comment 17

[Alice0775 White]

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

Comment 18

[Loic]

Attachment: Toolbar height: CNN.com (HTTP) vs Twitter.com (HTTPS), Firefox/12.0a1 in safe mode

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.

Comment 19

[Sid]

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

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Quick fix

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

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The tryserver builds will be here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-27ba095d2c1d/

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 593775 [details] [diff] [review]
Quick fix

I have no idea to test this patch.

Comment 25

[kolubinowicki]

Attachment: Video of Tryserver build

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

Comment 26

[kolubinowicki]

Attachment: Screenshot of Firefox interface with patch from tryserver build (search bar is not the same size as adress bar). See Comment 25 for more info.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch (removing unnecessary padding of #identity-box

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 29

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 594017 [details] [diff] [review]
Patch (removing unnecessary padding of #identity-box

Oh, this change causes a regression.

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 31

[Boris Zbarsky [:bzbarsky]]

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?

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 33

[Boris Zbarsky [:bzbarsky]]

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

Comment 34

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 35

[Boris Zbarsky [:bzbarsky]]

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?

Comment 36

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 37

[kolubinowicki]

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;
}

Comment 38

[pal-moz]

Attachment: screenshot

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

Comment 39

[Michał]

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

Comment 40

[Dão Gottwald [:dao]]

Does this still happen after bug 747608?

Comment 41

[Michał]

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

Comment 42

[pal-moz]

seems to be fine now.

Comment 43

[Loic]

Attachment: 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.

Comment 44

[Michał]

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

[Dão Gottwald [:dao]]

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.