3.83 KB, text/html
260 bytes, text/html
1.14 KB, patch
|Details | Diff | Splinter Review|
901 bytes, text/html; charset=UTF-8
296 bytes, text/html; charset=UTF-8
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.
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?
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.
The bug does not appear in this version.
WFM, probably fixed by one of roc's recent checkins.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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?
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Version: unspecified → Trunk
Yes, I do have to set the window width just right to force the split.
Created attachment 318854 [details] 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.
Summary: Text in a <nobr> breaks/wraps. → <nobr> content breaks/wraps near <table style="display:inline">
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> ?
I still see the bug after wrapping the table in an extra span.
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.
Created attachment 318910 [details] 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!
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Assignee: nobody → roc
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.
Created attachment 318991 [details] [diff] [review] 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?
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.
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.
Created attachment 319119 [details] 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.
It would? This testcase is in standards mode and I'm only changing quirk.css. Or did you mean that testcase without the doctype?
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.
Created attachment 319120 [details] a testcase to consider (quirks mode) Right, quirks mode this time.
Attachment #319119 - Attachment is obsolete: true
So currently we interoperate with Opera, Konqueror, and Safari on attachment 319120 [details]. I guess I'd rather not change that.
OK. Any ideas then?
Created attachment 319184 [details] 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).
Attachment #319119 - Attachment description: a testcase to consider → a testcase to consider (standards mode)
Attachment #319120 - Attachment description: a testcase to consider → a testcase to consider (quirks mode)
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.
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 ;)
Assignee: roc → nobody
You need to log in before you can comment on or make changes to this bug.