408241 - <nobr> content breaks/wraps near <table style="display:inline">

Status: NEW

(Core :: Layout: Block and Inline, defect)

Description

[Josh Mittleman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

In the first search result on this page, the link

 [+] Stock quote for IBM

is split across two lines in FF3.0b1.  In FF2 it is not.  It's in a NOBR, so I think it shouldn't.

Reproducible: Always

Steps to Reproduce:
1. In FF3.0b1, go to http://www.google.com/search?q=ibm
2. Make sure your browser window is wide enough so that the ads on the right-hand side aren't crowding the search results.

Actual Results:  
Link is split across two lines.

Expected Results:  
Link should wrap to the next line as a unit.

Comment 1

[Jesse Ruderman]

Works fine for me with a newer trunk build on Mac.  I tried various window sizes and "[+] Stock quote for IBM" always stays together on a line.

Do you still see this bug with a newer trunk nightly build?

Comment 2

[Josh Mittleman]

The version I was using was a couple weeks old.  if you point me at the installer for the latest version, I'll be happy to try it.

Comment 3

[Jesse Ruderman]

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/12/2007-12-14-05-trunk/

Comment 4

[Josh Mittleman]

The bug does not appear in this version.

Comment 5

[Jesse Ruderman]

WFM, probably fixed by one of roc's recent checkins.

Comment 6

[Josh Mittleman]

This bug has reappeared in FF3.0b5 in Win/XP (at least), for this page:

http://www.google.com/search?q=google

We've reproduced this on several machines.  

Thanks.

Comment 7

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008043015 Minefield/3.0pre

I can get the

  [+] Stock quote for GOOG

to split between the "[+]" and the "Stock quote for GOOG", but only if I resize the window so that the ad is close to the first search result.  I can't get it to split at any other point (e.g. between two words).  Is this the same thing you're seeing?

Comment 8

[Josh Mittleman]

Yes, I do have to set the window width just right to force the split.

Comment 9

[Jesse Ruderman]

Attachment: partially-reduced testcase

This seems to involve Google's use of <table style="display: inline">.  If you use "display: inline-table" on the table, or eliminate the table and use "display: inline-block" on the inner div, the buggy behavior goes away.

Comment 10

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

I was expecting to see an incorrect frame tree due to bug 363326 / bug 148810 / etc., but it looks OK, so it's not clear to me why this would be specific to <table style="display: inline">.  You still don't see the bug if you replace the <table style="display:inline">...</table> with <span><table style="display:inline-table">...</table></span> ?

Comment 11

[Jesse Ruderman]

I still see the bug after wrapping the table in an extra span.

Comment 12

[Jesse Ruderman]

Oh, I missed part of your comment.  The bug does go away if I wrap the table in a span and make the table be inline-table instead of inline.  Or if I just make the table be inline-table.

Comment 13

[Jesse Ruderman]

Attachment: simple testcase

This testcase shows the difference between Firefox 2 (doesn't wrap) and Firefox 3 (wraps) clearly.  It seems that the bug only happens in quirks mode, and only if the 'q' is not followed by whitespace!

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The style="display:inline" turns the <table> element into a regular inline element like a span --- the real table is an anonymous thing we construct to contain the <tr>. Our quirk.css stylesheet has a rule "white-space:normal" on <table>, so everything inside this <table> is white-space:normal even though it's an inline element not a real table... We allow a break opportunity after an inline-table in a white-space:normal context, and that applies here to our anonymous table. So we break.

I'm not sure what to do here. Perhaps the best thing would be for that quirk.css white-space:normal rule to apply only to display:table or display:inline-table <table> elements. However, that is not expressible in CSS.

That rule was added for bug 84378. Unfortunately it's not clear why the patch took the final form it did.

Could we just move the white-space:normal rule from <table> to <tbody>, and add also add white-space:normal for ::-moz-table-row-group in quirk.css? That would produce the expected behaviour for people using display:inline <table>s.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix?

Here's the patch. I'm uncertain if it's the right thing to do. It doesn't seem risky but I'm not 100% sure. David, what do you think?

Comment 16

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

It seems pretty safe.  It's not clear to me what whitespace inside the table element but outside the anonymous table box the 'white-space: normal' is applying to, though.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There is no such whitespace. But we're using 'white-space' to control whether we allow soft breaks of any kind:
http://mxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#1036
For better or worse there is ample precedent for this.

Comment 18

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

Attachment: a testcase to consider (standards mode)

This change would influence our behavior on this testcase.

IE7's behavior here doesn't particularly make sense, though.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It would? This testcase is in standards mode and I'm only changing quirk.css. Or did you mean that testcase without the doctype?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Assuming you meant a quirks-mode version of that testcase, then it would change the behaviour here only, AFAIK:

<table border style="white-space: pre" width="1"><tr><td>
Should this all be on one line?
</td></tr></table>

"pre" would be overridden by "normal" in <tbody>.

But IE7 quirks mode is going crazy and apparently suppressing white-space:pre anywhere inside the table subtree, so it does seem this is unlikely to cause any problems for quirks-mode documents.

Comment 21

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

Attachment: a testcase to consider (quirks mode)

Right, quirks mode this time.

Comment 22

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

So currently we interoperate with Opera, Konqueror, and Safari on attachment 319120 [details].  I guess I'd rather not change that.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK. Any ideas then?

Comment 24

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

Attachment: standards mode testcase

Here's a standards mode testcase for the line breaking bug.  I'm not entirely sure which behavior is correct, but whether to break between the table and the q definitely shouldn't depend on whether there is whitespace after the nobr (which it in fact does).

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In the standards mode testcase, we record a soft break opportunity after the table (in nsLineLayout::ReflowFrame), but we don't take it because we only look at these recorded opportunities when an inline frame returns break-before or break-after in its reflow status. The table did not return a break status, and the following text frame has no break opportunity in it so it also does not return break-before or break-after.

The best fix for that is probably to make nsLineLayout::ReflowFrame, where it calls NotifyOptionalBreakPosition to record the soft break after a replaced element, also check whether the element's edge exceeds the available width and if so change its break status to break-after.

However, that will fix the inconsistency by making us *always* break regardless of what's after the table, which is not what is wanted in this bug. So I still think the fix for this bug should involve making <table style="display:inline"> not get "white-space:normal" from quirk.css, although I don't see how to do that.

Comment 26

[Josh Mittleman]

We observed this problem in Firefox 3.0 on OSX.  (OSX doesn't give us a more precise version number, but the person who installed it says it's the latest version.  If there's a way to get the version details, let me know and I'll get 'em.)

We also noticed the problem in Safari 2.0.4 on OSX, in case that's of interest ;)