1221969 - www.forestfinance.de makes bogus assumptions about font metrics

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Nico R]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36

Steps to reproduce:

Ever since the update to Firefox 42 on my Kubuntu 15.10 system, a float:left div on our website doesn't float anymore; this appears also reproducible on OS X, so it seems to affect Firefox on unixoid systems. With Firefox 42 on Windows, everything looks like it should as well.

The site affected is http://www.forestfinance.de/en/about-us/ and all other pages on the website: The div #linke_spalte should float left, but it doesn't.

Interesting: If I trigger the application of its float:left property, it's actually reversed to what it should be.

1. Right-click in the obviously shifted menu with the buttons "TreeSavingsPlan", "GreenAcacia" etc.
2. Inspect element
3. In the document tree, navigate to div #linke_spalte
4. In the right part of the debug console, tick or untick the float:left property

Also, I compared the page via browsershots.org and all browsers display it correctly.


Actual results:

When float:left is active, the container is shifted to somewhere in the right part of the page; also, other content doesn't float around it. When it's inactive (deactivated via console), the float:left behavior is working.


Expected results:

It should be the other way round, obviously.

Comment 1

[Simona Badau, Desktop QA]

Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151108030417

I could not reproduce the issue on Ubuntu 14.04 using the latest Nightly. I see the same result on Firefox 41.0.2, 45.0a1 or Chrome.

Nico R, please can you confirm whether this issue is still reproducible when you start Firefox with a new profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Nico R]

Dear Simona,

thanks for your response!

I created a new profile and the issue is still present. I created screenshots of the behavior which should illustrate the problem sufficiently:

http://tubemail.de/~nico/firefox1.jpg
http://tubemail.de/~nico/firefox2.jpg
http://tubemail.de/~nico/firefox2.jpg

Hope this helps!

Kind regards
Nico

Comment 3

[Nico R]

Sorry, the last one should obviously be
http://tubemail.de/~nico/firefox3.jpg

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

This seems like a layout problem, since the issue is present even without changing anything in the DevTools.

Comment 5

[Boris Zbarsky [:bzbarsky]]

David, could this be more fallout from your float changes?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hard for me to tell, since I don't see the bug on my machine.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Nico R, would you be willing to use http://mozilla.github.io/mozregression/ to figure out when the problem first appeared?

Comment 8

[Ryan VanderMeulen [:RyanVM]]

I was able to reproduce the problem on Ubuntu 15.10 (but not on Windows, same as #c0).

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ac376a4e8174&tochange=c8055a00235d

Too old for automated inbound bisection. I don't see any obvious culprits, though there are some layout patches in that range. Hopefully someone with a better idea can spot a good candidate.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmm.  That regression range doesn't quite match the "since updating to 42" bit from comment 0.

In any case, in that range what jumps out at me is bug 947650 (which can change font metrics and hence sizes and hence float behavior).  I guess it's possible something else changed in Linux font metrics in some cases in 42; that would be consistent with the problem not appearing on other OSes.

If someone who can actually reproduce can try creating a minimal testcase, that would be pretty helpful in terms of figuring out what the relevant bits are here.

Comment 10

[Nico R]

(In reply to Boris Zbarsky [:bz] from comment #9)
> Hmm.  That regression range doesn't quite match the "since updating to 42"
> bit from comment 0.

An friend of mine told me that he experiences it on MacOS X with Firefox 41.0.2 as well, so it's possible that I jumped over a few updates which may have broken this already.

As for Comment #7 (asking me to test with mozregression), I will try to have a look into it.

Comment 11

[Boris Zbarsky [:bzbarsky]]

A, I see it on Mac in Fx41.  It's definitely font-size dependent; e.g. zooming in changes the behavior.

The basic problem is that the site is buggy as far as I can tell.  It has the following general structure, with the relevant styles inlined:

  <div id="head_fofi" style="height: 175px">
    <a>
      <img height="139" src="fileadmin/templates/img/head_transparent.gif">
    </a>
    <div id="navigation" style="margin-top: 5px">
      <ul id="navlist" style="height: 1.05em; position: relative; bottom: 6px">
        <li style="float: left">
          <a style="padding-top: 0.4em; padding-bottom: 0.7em;
                    font: 0.7em/120% Verdana,Arial,Helvetica,sans-serif">
            Text
          </a>
        </li>
        <!-- More <li>s like that here -->
      </ul>
    </div>
  </div>
  <div id="linke_spalte" style="float: left; margin-top: -6px">stuff</div>

Figuring out the behavior here involves understanding the sizes of those things sized in "em".  For <ul id="navlist">, the font-size is 16px, so its height is 1.05*16 = 16.8px.  For the <a> inside the floating <li>, the font-size is 0.7*16 == 11.2px, so the top padding is 4.48px and the bottom padding is 7.84px.  The height of the text inside that <a> is, for me, with the font it ends up with, 13.43px.  So the total height of the <a> is 25.75px.  Note that this is larger than the 16.8px height of the <ul> so the <a> is sticking out the bottom of the <ul>.

The other thing we need to understand is that the site is in standards mode, so there is space inside the <a> containing the <img> for descenders. That space is below the <img>.  With the fonts I seem to have, that space is 4px.

I'm now going to measure all vertical distances from the top of the <div id="head_fofi">.

The bottom of the <a> is at 139px+4px = 143px. There is 5px of top margin on the <div id="navigation"> plus an offset of 1.6px that I can't quite figure out yet, probably due to the strut on the previous line.  So the top of the <div id="navigation"> is at 149.6px.  There is a 6px negative offset on the <ul id="navlist">, so its top is at 143.6px.  The <li> inside is 25.75px tall, so it bottom is at 169.35px.

Now the top of the <div id="linke_spalte"> is at 175px (height of the <div id="head_fofi">) minus the 6px of negative top margin it has, so 169px.

As you will note, 169 < 169.35.  Per CSS float rules, the <div id="linke_spalte"> needs to be to the right of the last <li> inside the <ul> (assuming there's enough horizontal space for it there), which is what you're seeing.

Note that this is all _very_ dependent on the exact font metrics and how things get rounded and so forth.  If the font metrics for the <a> containing the <img> had a 3px descent instead of a 4px one, there would be no problem here.

The right way to do what the site is doing, of course, is to put "clear: left" on the <div id="linke_spalte"> so it clears the floats above it and floats all the way over to the left, which is what the site wants.

Comment 12

[Karl Dubost💡 :karlcow]

Nico R 
> a float:left div on our website doesn't float anymore

As you reported the bug as "our" Website, do you have enough information to fix it?

Thanks. 

PS: Boris, Thanks a lot for the analysis.

Comment 13

[Nico R]

Indeed, thanks from me as well to Boris for the extensive analysis!

I hope I'm acting correctly by setting this to RESOLVED INVALID since it's not a Firefox bug but rather a compatibility issue on the website.

Thank you all very much for your efforts!

Comment 14

[Boris Zbarsky [:bzbarsky]]

Nico, you're welcome!

Actually, the bug is now in the "technology evangelism" product, which means it's marked "fixed" when the site is fixed.  Which it looks like it is; there's a "clear: left" there now.  ;)