Closed
Bug 352949
Opened 19 years ago
Closed 19 years ago
[reflow branch] table not rendered properly on gmail.com
Categories
(Core :: Layout: Tables, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: romaxa, Assigned: bzbarsky)
References
()
Details
Attachments
(7 files, 1 obsolete file)
Gmail rendered by trunk mozilla
gmail.com not rendered properly with reflow branch....
This simple testcase - bad part og mail.com:
.............................
<html>
<body>
<table border="1">
<td nowrap="nowrap" width="1%">
<input value="Mail Search" type="submit">
<input value="Web-Search" type="submit">
</td>
<td>Show search options</td>
</table>
</body>
</html>
........................
With current trunk all works fine....
|
Reporter | |
Comment 1•19 years ago
|
||
|
|
Reporter | |
Comment 2•19 years ago
|
||
|
|
Reporter | |
Comment 3•19 years ago
|
||
|
|
Reporter | |
Comment 4•19 years ago
|
||
|
|
Reporter | |
Comment 5•19 years ago
|
||
|
Assignee | |
Updated•19 years ago
|
Summary: [reflow_branch] table not rendered properly on gmail.com → [reflow branch] table not rendered properly on gmail.com
|
|
Assignee | |
Comment 6•19 years ago
|
||
Attachment #238775 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 7•19 years ago
|
||
So the issue is that buttons don't implement AddInlineMinWidth and don't implement CanContinueTextRun. So for GetMinWidth purposes, breaking both before and after buttons is ok, no matter what the whitespace style. This last part is probably wrong.
Oh, did I forget to check the white-space style when I called CanContinueTextRun in the default GetMinWidth?
er, in nsFrame::AddInlineMinWidth
|
|
Assignee | |
Comment 10•19 years ago
|
||
|
|
Assignee | |
Comment 11•19 years ago
|
||
David, sounds like we're on the same wavelength here... ;) Could you just check it over to make sure we really are? The nsLineLayout changes are cleanup, and I could just hold on them for now if you prefer.
Attachment #238827 -
Flags: review?(dbaron)
Comment on attachment 238827 [details] [diff] [review]
Patch I wrote before seeing comment 8
Looks good, although you might want to check (in all 3 cases) which frame you're checking against what the spec says -- our existing code for supporting 'white-space' on inlines is rather buggy and hasn't really been validated against the spec.
Attachment #238827 -
Flags: review?(dbaron) → review+
|
|
Reporter | |
Updated•19 years ago
|
Attachment #238827 -
Flags: review+
|
|
Assignee | |
Comment 13•19 years ago
|
||
> against what the spec says
The spec doesn't define the line-breaking behavior of replaced elements. In fact, all it really has to say on the matter that I've found is:
Note. CSS 2.1 does not fully define where line breaking opportunities occur.
Floated and absolutely-positioned elements do not introduce a line breaking
opportunity.
and
If an inline box cannot be split (e.g. if the inline box contains a single
character, or language specific word breaking rules disallow a break within
the inline box, or if the inline box is affected by a white-space value of
nowrap or pre), then the inline box overflows the line box.
(without defining what "affected by" means).
Assignee: nobody → bzbarsky
|
|
Assignee | |
Comment 14•19 years ago
|
||
Fixed.
romaxa, thanks for the excellent testcase!
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 15•19 years ago
|
||
Tested and accepted.
Closing.
PS: bz, thanks for fast bugfix ;)
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•