Open Bug 689079 Opened 13 years ago Updated 2 years ago

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

Categories

(Firefox :: Theme, defect)

x86
Windows 7
defect

Tracking

()

People

(Reporter: tetsuharu, Unassigned)

References

Details

(Keywords: regression)

Attachments

(9 files, 3 obsolete files)

Attached image screenshot (obsolete) —
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.
Blocks: 684450
Hardware: x86_64 → x86
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
Attached image 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.
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?
Attachment #580626 - Attachment mime type: application/octet-stream → video/webm
Attachment #574641 - Attachment mime type: application/octet-stream → video/webm
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;
}
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Keywords: regression
WORKAROUND2(preserve font-family):
#page-proxy-stack {
margin-top: 1px !important;
}
Summary: toolbar height increases 1px when current tab is SSL page → toolbar height increases 1px when current tab is SSL page with HWA enabled
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
Attached patch Quick fixSplinter Review
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
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).
Summary: toolbar height increases 1px when current tab is SSL page with HWA enabled → toolbar height increases 1px when current tab is SSL page
Comment on attachment 593775 [details] [diff] [review]
Quick fix

I have no idea to test this patch.
Attachment #593775 - Flags: review?(gavin.sharp)
Attachment #593775 - Flags: review?(gavin.sharp) → review?(dao)
(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.
Attachment #594017 - Flags: review?(dao)
Comment on attachment 594017 [details] [diff] [review]
Patch (removing unnecessary padding of #identity-box

Oh, this change causes a regression.
Attachment #594017 - Flags: review?(dao) → review-
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;
}
Attached image screenshot
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...
Attachment #583993 - Attachment is obsolete: true
Attachment #562344 - Attachment is obsolete: true
Attachment #594017 - Attachment is obsolete: true
Summary: toolbar height increases 1px when current tab is SSL page → Location bar height increases by 1px on pages with EV SSL
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.
Attachment #593775 - Flags: review?(dao) → review-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: