488725 - float pushed down one line with white-space: nowrap;

Status: VERIFIED FIXED

(Core :: Layout: Floats, defect, P2)

Description

[tehwhale]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.53 Safari/525.19
Build Identifier: 3.0.8

On my blog, when using the style "float:right;" to bring text to the farthest side, on the same line, it will move all the text in the "float:right;" down, much farther than it should be. Opera/Safari/Chrome all display it fine.

Reproducible: Always

Steps to Reproduce:
1.Go to http://tehwhale.co.uk
2.On the right side of all blog posts it displays [Permalink] farther down
3.
Actual Results:  
The same thing, all the text thats in the float:right; style will go down a good bit, rather than being on the same line

Expected Results:  
It should have put the text on the same line, as everything else, just move it to the outside of the divison class it's in.

Comment 1

[Daniel.S]

In the case of [Permalink] it's a know bug, that will be fixed in the Firefox 3.5 release.

However, I noticed that one float doesn't work as it should. That's because white-space: nowrap; is set on the parent element. Testcase on the way.

Comment 2

[Daniel.S]

Attachment: testcase

Comment 3

[tehwhale]

Cool, thanks.

Comment 4

[Laurent Dorier]

Any chance to see this bug fixed ? ^^
It's currently only working if the floating element is included at first.

Try the previous attachment from Daniel.S to see an example.

Thanks !

Comment 5

[k.dalgard]

Have the same problem. Made a quite concise test case here (with inline-blocks):

http://jsfiddle.net/dalgard/zWxbL/show/

Comment 6

[004a0041]

this also occurs with white-space: pre, probably because its behavior is a superset of white-space: nowrap.

Comment 7

[Jasper St. Pierre]

This is causing GitHub's boxes of notification counts to look incorrect (the number is placed on another line).

Comment 8

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

Also affecting Bugzilla itself, as glob pointed out on IRC.
https://bugzilla.mozilla.org/show_bug.cgi?id=677757#c4 has the "comment 4" text hidden

The cause is this code in nsLineLayout::ReflowFrame:
        if (psd->mNoWrap) {
          // If we place floats after inline content where there's
          // no break opportunity, we don't know how much additional
          // width is required for the non-breaking content after the float,
          // so we can't know whether the float plus that content will fit
          // on the line. So for now, don't place floats after inline
          // content where there's no break opportunity. This is incorrect
          // but hopefully rare. Fixing it will require significant
          // restructuring of line layout.
          // We might as well allow zero-width floats to be placed, though.
          availableWidth = 0;
        }

I wonder whether the right thing to do is:
 * not manipulate the available width at all, or
 * make the available width infinite, since the nowrap content is never going to wrap around the float anyway

(In theory, the correct solution is not to try placing the float until the following break opportunity.  I wonder if other browsers do that.)

Comment 9

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

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #8)
> (In theory, the correct solution is not to try placing the float until the
> following break opportunity.  I wonder if other browsers do that.)

I actually think this is quite doable; we already defer layout of floats in mBelowCurrentLineFloats; we just need to do something similar and notify line layout at break opportunities.  It's far from trivial, though.  (We also need to place the float immediately if we're currently at a break opportunity... I think.)

Comment 10

[Laurent Dorier]

(In reply to Laurent Dorier from comment #4)
> Any chance to see this bug fixed ? ^^
Probably not... :(

Comment 11

[gavenkoa]

I traped to this "bug" when try to aligh to right triangle in for submenus elements in vertical menu:

http://stackoverflow.com/questions/25006130/align-to-right-left-triangle-in-menu-element

My workaround was used padding-right (place for triangle), negative margin-left and "position: absolute" on trinagle.

See problem on: http://jsfiddle.net/ZZ4xM/7/ and http://jsfiddle.net/ZZ4xM/1/

See solution on: http://jsfiddle.net/m6vU4/1/

Also I found these user problems:

 * stackoverflow.com/questions/12407541/white-space-nowrap-vs-white-space-normal-why-is-the-effect-on-floating-element/ or http://jsbin.com/ibifoq/23/edit

Comment 12

[marek]

Minimal example of this bug: http://jsfiddle.net/en7qfto1/

Comment 14

[kenjiru]

Still happens in Firefox 33. These kind of bugs seem to stick around forever in Firefox..

Comment 15

[fanqi1234]

Still happens in Firefox 38.

Comment 16

[themicon]

> Still happens in Firefox 38.
> It's currently only working if the floating element is included at first.

Comment 17

[Behrang]

I've found a similar issue: https://github.com/w3c/csswg-test/issues/839

Should I open a new ticket? Or will fixing this bug fix that as well?

Comment 18

[Craig Kovatch]

(In reply to David Baron [:dbaron] ⌚UTC-7 from comment #9)
> (In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #8)
> > (In theory, the correct solution is not to try placing the float until the
> > following break opportunity.  I wonder if other browsers do that.)
> 
> I actually think this is quite doable; we already defer layout of floats in
> mBelowCurrentLineFloats; we just need to do something similar and notify
> line layout at break opportunities.  It's far from trivial, though.  (We
> also need to place the float immediately if we're currently at a break
> opportunity... I think.)

Just hit this problem in FF 40.0.3. Seems like David diagnosed correctly here ^

Comment 19

[zegenie]

I also hit this bug with a container used for holding a set of <button> elements. The container element has white-space: nowrap, and the last button floats right, resulting in it being pushed down.

Comment 20

[brandon.dusseau]

I am encountering this issue in Firefox 46.0.1.

Comment 21

[yves.piguet]

Same issue in Firefox 47.0.1 and 49.0a2.

I'm trying to use a floating span in a li for the shortcut of a dropdown menu, with li{white-space:nowrap;} and span.shortcut{float:right;} (+padding etc. which don't have any effect on the issue). The vertical position of the span.shortcut element is correct if the white-space of the parent li element is normal, pre-line, pre-wrap, or unset; and about 1em too low if it's nowrap, pre, or -moz-pre-space. I need nowrap to avoid word-wrap when the space is tight.

Comment 22

[henrique.barcelos]

Reproducing the same issue in Firefox 48.

Comment 23

[hmmterve]

Still in Firefox 51.0.1

Comment 26

[Mike Taylor [:miketaylr]]

(setting to webcompat:p2, this can affect google tier 1 search and other sites)

Comment 27

[Mike Taylor [:miketaylr]]

ni? Maire to find an owner for this bug.

Comment 28

[Bobby Holley (:bholley)]

Maire is out this week, switching NI to Cameron.

Comment 29

[Cameron McCormack (:heycam)]

Sean is finding an owner for this. :-)

Comment 30

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Ni myself to take a look at this.

Comment 31

[franck.farmer456]

Hello,
Is this bug still open or has it been fixed? Can I work on it for my first bug?

Comment 32

[Julien Desgats]

Hi,

It is still happening to me. Example on this page: https://purecss.io/layouts/marketing/ (and proposed workaround: https://github.com/pure-css/pure-site/pull/319)

Comment 33

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

This isn't a good choice for a first bug; it makes more sense for somebody with a bit of experience working on layout already.

Comment 34

[Sean Voisen (:svoisen)]

Emilio is also going to take a look.

Comment 36

[Emilio Cobos Álvarez (:emilio)]

Attachment: Don't position floats in a nowrap context until hitting a break opportunity.

I pushed this to see whether something in try was broken, and only got passes
(except for a grid container reference test on which we're correct with this
patch and match Chrome).

I suspect we could be pragmatic and land this given it's only a progression,
but could you describe the cases that require the more complicated approach
here?

I tried to play a bit forcing line-breaking in <br> and such and didn't manage
to come up with a testcase that differed from WebKit / Blink. I suspect it
wouldn't be too hard to come up with one.

Comment 37

[Emilio Cobos Álvarez (:emilio)]

David, could you help me / TYLin out to come up with a test-case that requires the more complicated approach from comment 8 / comment 9?

I haven't tried that hard, but I suspect you'd be able to come up with one way more easily than I :)

Comment 38

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

Attachment: an example where Chromium is clearly not following the spec

I don't have Edge to test right now, but...


Here's one example where Chromium is clearly not following float positioning rule 6:

  6. The outer top of an element's floating box may not be higher than the top of any line-box containing a box generated by an element earlier in the source document. 

from https://drafts.csswg.org/css2/visuren.html#float-position .

Comment 39

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

Attachment: an example where the spec might be unclear

Here's an example where the spec might be unclear, and I'm curious what Edge does' but Chromium has the text overlap the float.  I think the spec might say what I've written in the test, though, but it's not 100% clear that the rule that:

    If a shortened line box is too small to contain any content, then the line box is shifted downward (and its width recomputed) until either some content fits or there are no more floats present.

applies to lines that are entirely 'nowrap'.

Comment 40

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

I'd like to look at WebKit and Edge behavior as well later, but I suspect it may well be reasonable to make this change and file followup bugs (and maybe also spec issues) on remaining pieces.

Comment 41

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

So right now, Firefox and Edge match on attachment 9002875 [details] (and Chromium/WebKit differ in a way that's clearly nonconformant).  The same pairs of behavior occur on attachment 9002878 [details], although in that case all browsers agree that nowrap lines shouldn't push down around floats that are entirely before them (which is the thing that's not clear in the spec).

I'd be happier if the patch gives us the Edge behavior than if it gives us the Chromium/WebKit behavior on attachment 9002875 [details], given that the latter clearly doesn't match the spec (and it's not even clear to me how to fix the spec to do what Chromium does).  I think that depends on whether our line-redo logic catches this case and redoes the reflow of the line... which I think would mean that the more complex thing in comment 8 and comment 9 isn't necessary.

It's probably worth adding variants of a bunch of these tests to web-platform-tests...

Comment 42

[Emilio Cobos Álvarez (:emilio)]

Alright, I'll try to poke at it. Thanks for the pointers! Will ask if I get stuck :)

Comment 43

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

Comment on attachment 9002804 [details]
Don't position floats in a nowrap context until hitting a break opportunity.

David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 has approved the revision.

Comment 44

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

Oh, and after the revisions and new tests requested, I'd also be interested in hearing where we differ from Chrome and from Edge.

Comment 45

[Emilio Cobos Álvarez (:emilio)]

Attachment: float-nowrap-9.html differences across engines.

This is similar to attachment 9002875 [details]. As expected patched firefox (left) agrees with Edge, and Chromium and WebKit agree on the broken behavior.

Comment 46

[Emilio Cobos Álvarez (:emilio)]

Attachment: float-nowrap-8.html differences across engines.

Pretty much as above.

Comment 47

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #46)
> Created attachment 9003476 [details]
> float-nowrap-8.html differences across engines.
> 
> Pretty much as above.

float-nowrap-7.html looks the same.

Comment 48

[Emilio Cobos Álvarez (:emilio)]

Attachment: float-nowrap-4.html differences across engines.

This one is interesting. We start agreeing with Chromium and WebKit on the correct behavior. I think it's an edge bug that they don't manage to place the float on the first line. The container has `width: 10ch`, and the float `width: 5ch`, and there are five monospace characters to the left (Some ), which are not in a nowrap context, so the float should fit.

Comment 49

[Emilio Cobos Álvarez (:emilio)]

Attachment: float-nowrap-3.html differences across engines

Only Chromium does something broken here.

Comment 50

[Emilio Cobos Álvarez (:emilio)]

Try looks good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f19748251dd19065fc79942dc9d960560c5dbb5c

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a4eef4b8a3b0
Don't position floats in a nowrap context until hitting a break opportunity. r=dbaron

Comment 52

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Emilio, thank you for looking into this.

Comment 53

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/a4eef4b8a3b0

Comment 54

[Craig Kovatch]

This 10-year-old bug fix makes me believe we might actually survive as a species. HUZZAH!

Comment 55

[Chris Peterson [:cpeterson]]

status-firefox62=wontfix because we don't need to uplift this fix to 62 Beta.

Comment 56

[Oana Botisan, Desktop QA]

I managed to reproduce the issue using the test case attached to comment 2 on an older version of Nightly (2018-06-15).
I retested everything using beta 63.0b7 and latest Nightly 64.0a1 on Windows 10 x64, macOS 10.13 and Ubuntu 16.04 x64. The bug is not reproducing anymore.