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.

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.

Cool, thanks.

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 !

Have the same problem. Made a quite concise test case here (with inline-blocks): http://jsfiddle.net/dalgard/zWxbL/show/

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

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

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

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

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

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

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

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?

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

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.

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

ni? Maire to find an owner for this bug.

Maire is out this week, switching NI to Cameron.

Sean is finding an owner for this. :-)

Ni myself to take a look at this.

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

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)

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.

Emilio is also going to take a look.

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.

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

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 .

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

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.

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

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

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.

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

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

Pretty much as above.

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

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.

Only Chromium does something broken here.

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

Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/mozilla-inbound/rev/a4eef4b8a3b0 Don't position floats in a nowrap context until hitting a break opportunity. r=dbaron

Emilio, thank you for looking into this.

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

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

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.