This Microsoft page has a bunch of adjacent <nobr></nobr> tags in their breadcrumb view. WebKit should wrap inbetween the nobr tags. This may be related to bug 10145.
Maybe in quirks mode. I'm not convinced it should in strict mode.
Created attachment 11892 [details] Simple nobr test
Why should it not be in strict mode? I thought the point of <nobr> was to prevent content inside the tag from word breaking. However, between the <nobr> tags is an opportunity for breaking. Or rather, is it documented it shouldn't break? Other browsers break in strict mode.
Break opportunities don't automatically exist in between inline elements. Consider this: <span>A</span>pp<span>l</span>le This is all one word, "Apple", despite having multiple inlines wrapping some of the letters. Whether or not a break opportunity exists depends on the prevailing white-space mode (in this example "normal") and whether or not there's a break opportunity between two characters. In the case of <nobr>, the white-space mode is "nowrap", meaning that everything inside a <nobr> is considered to be unbreakable. When two of these elements are contiguous, the break opportunity between the two characters at the edges of the <nobr>s does not exist.
If a space or newline is in between the <nobr>s then we would break.
Our whitespace handling when mixing modes is way more advanced than other browsers. Take, for example: http://hixie.ch/tests/adhoc/css/text/white-space/mixed/001.html
Note that in Firefox for a line break to occur between adjacent <nobr>s, either the first one must end with whitespace or the second one must begin with whitespace, i.e. <nobr>No</nobr><nobr>break</nobr> won't wrap, but the following will <nobr>No </nobr><nobr>break</nobr> <nobr>No</nobr><nobr> break</nobr>
In this case, there is whitespace before the closing tag, as mitz says.
I think this bug (or maybe a variant of it) exists on http://login.live.com/?id=2. (Depending on your font settings, you might need to increase font sizes to see it.) Notice that in WebKit the "Account Services | Privacy Statement | Terms of Use" line doesn't break, whereas in all other browsers it does.
(In reply to comment #9) > I think this bug (or maybe a variant of it) exists on > http://login.live.com/?id=2. (Depending on your font settings, you might need > to increase font sizes to see it.) > > Notice that in WebKit the "Account Services | Privacy Statement | Terms of > Use" line doesn't break, whereas in all other browsers it does. > Yup, I think bug 17595 is a duplicate of this bug.
*** Bug 17595 has been marked as a duplicate of this bug. ***
WebKit's old behaviour was correct but has now regressed and 'passes' the reduction in this bug; it breaks between the <nobr> tags.
(In reply to comment #12) > WebKit's old behaviour was correct but has now regressed and 'passes' the reduction in this bug; it breaks between the <nobr> tags. Turns out I'm the culprit: https://bugs.webkit.org/show_bug.cgi?id=29648. This bug seems like the right place to fix it.
Created attachment 180809 [details] Patch
Comment on attachment 180809 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=180809&action=review > Source/WebCore/rendering/RenderBlockLineLayout.cpp:3085 > + } else if (blockStyle->autoWrap() && !width.fitsOnLine() && !width.committedWidth()) > + // If the container autowraps but the current child does not then we still need to ensure that it > + // wraps and moves below any floats. > + width.fitBelowFloats(); I believe the "official" style is to wrap such blocks in {}, even though some of the lines are only comments. Sad that check-webkit-style doesn't enforce this.
Created attachment 180822 [details] Patch
Comment on attachment 180822 [details] Patch r=me
Comment on attachment 180822 [details] Patch Clearing flags on attachment: 180822 Committed r138630: <http://trac.webkit.org/changeset/138630>
All reviewed patches have been landed. Closing bug.