Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Setting text to empty directly inside TABLE leaves a small gap




Layout: Tables
11 years ago
8 years ago


(Reporter: Jesse Ruderman, Unassigned)


(Blocks: 1 bug, {regression, testcase})

Mac OS X
regression, testcase
Dependency tree / graph
Bug Flags:
blocking1.9 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [dbaron-1.9:RwCo])


(4 attachments, 1 obsolete attachment)



11 years ago
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.

Comment 1

11 years ago
Created attachment 257317 [details]
372641-1a.xhtml (text in TABLE)

Comment 2

11 years ago
Created attachment 257318 [details]
372641-1b.xhtml (text in TBODY)

Comment 3

11 years ago
Created attachment 257319 [details]
372641-1c.xhtml (text in TR) (gap is horizontal rather than vertical)

Comment 4

11 years ago
Created attachment 257320 [details]


11 years ago
Blocks: 373610

Comment 5

11 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?

Comment 6

11 years ago
Regressed between 2007-01-29 and 2007-01-31.
Keywords: regression
Flags: blocking1.9? → blocking1.9+

Comment 7

10 years ago

Comment 8

10 years ago

Comment 9

10 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

10 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
Whiteboard: [dbaron-1.9:RwCo]

Comment 11

10 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-


8 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

8 years ago
Will be fixed by the patch in bug 484448.
Depends on: 484448
No longer depends on: 162063

Comment 14

8 years ago
Created attachment 373294 [details] [diff] [review]

(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)


8 years ago
Last Resolved: 8 years ago
Flags: in-testsuite?
Resolution: --- → FIXED

Comment 15

8 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
Flags: in-testsuite? → in-testsuite+


8 years ago
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.