Closed
Bug 372641
Opened 18 years ago
Closed 16 years ago
Setting text to empty directly inside TABLE leaves a small gap
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: regression, testcase, Whiteboard: [dbaron-1.9:RwCo])
Attachments
(4 files, 1 obsolete file)
If there is some text directly inside a TABLE (or TBODY or TR), and I remove it by setting the text node's data to the empty string, a small gap remains, leaving the table asymmetric. I will attach reftests.
|
Reporter | |
Comment 1•18 years ago
|
||
|
|
Reporter | |
Comment 2•18 years ago
|
||
|
|
Reporter | |
Comment 3•18 years ago
|
||
|
|
Reporter | |
Comment 4•18 years ago
|
||
|
||
Comment 5•18 years ago
|
||
Hmm. The immediate problem is that those pseudo-frames are not being removed, but we shouldn't be creating those pseudo-frames at all, should we? See the NeedFrameFor() check in nsCSSFrameConstructor::ConstructFrame. Bernd, any idea what's up here?
Also, is this a regression? I rather suspect it is...
Severity: minor → normal
Flags: blocking1.9?
|
||
Updated•18 years ago
|
Flags: blocking1.9? → blocking1.9+
|
|
||
Comment 9•17 years ago
|
||
I see a different regression range: between 2007-02-01-01 and 2007-02-02-01 ? Nothing jumps out at me there either...
|
|
||
Comment 10•17 years ago
|
||
Oh, wait. NeedFrameFor only triggers on whitespace-only text. So we do expect pseudos here, and this is basically bug 162063 in a different form.
Depends on: 162063
|
|
||
Updated•17 years ago
|
Whiteboard: [dbaron-1.9:RwCo]
|
|
||
Comment 11•17 years ago
|
||
OK. I see what happened here.
On branch, the <script> runs before we ever start layout, so the frame model doesn't have to deal with that dynamic change.
On trunk, we started doing incremental XML layout. So now we're flushing out the layout for the offsetWidth get, then it has to update dynamically in response to the text set and fails. Of course in HTML, this has been a problem all along.
As far as the regression range goes, the range I'm getting includes the fix for bug 369011. Until that fix, flushing the XML content sink randomly didn't work (because sometimes it thought that it was in the middle of a notification when it actually wasn't). I still have no idea where Jesse's range comes from, other than the likely "something changed what value happened to be at that uninitialized memory location" reason.
I don't think this bug should be a blocker. Especially because it's not even clear what the right layout of this sort of markup is. I posted to www-style about that; no response so far other than the "it's been added to the issues list" boilerplate.
OK, we'll reevaluate...
Flags: blocking1.9+ → blocking1.9?
Flags: blocking1.9? → blocking1.9-
|
|
||
Updated•16 years ago
|
Summary: Removing text directly inside TABLE leaves a small gap → Setting text to empty directly inside TABLE leaves a small gap
|
|
||
Comment 13•16 years ago
|
||
Will be fixed by the patch in bug 484448.
|
||
Comment 14•16 years ago
|
||
(In reply to comment #13)
> Will be fixed by the patch in bug 484448.
Yeah, the checkin of bug 484448 fixed this issue.
Attachment #373294 -
Flags: review?(bzbarsky)
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
|
|
||
Comment 15•16 years ago
|
||
Oh, I totally forgot to close this; thank you for noticing that! I landed tests for this as part of the patch in bug 484448. See http://mxr.mozilla.org/mozilla-central/find?string=372641&tree=mozilla-central&hint=
Flags: in-testsuite? → in-testsuite+
Attachment #373294 -
Attachment is obsolete: true
Attachment #373294 -
Flags: review?(bzbarsky)
You need to log in
before you can comment on or make changes to this bug.
Description
•