Closed
Bug 697793
Opened 13 years ago
Closed 13 years ago
dynamic change setting 'float' leaves a blank line for what should be ignored whitespace
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 713856
People
(Reporter: ayg, Unassigned)
References
Details
(Keywords: regression)
Attachments
(4 files, 1 obsolete file)
Steps to reproduce: 1) Go to http://software.hixie.ch/utilities/js/live-dom-viewer/ (does not reproduce for me using a data URL, but does work if I save it as a file) 2) Enter the following markup: <!doctype html> <ol> <li> <p>foo <p>bar </ol> <script> setTimeout(function(){document.querySelector("p").setAttribute("style", "float:right")}, 0) </script> 3) Observe that there's extra space above "bar"; it's below the list marker 4) Get rid of the setTimeout in the script line, so it's just <script> document.querySelector("p").setAttribute("style", "float:right") </script> 5) Observe that there's no extra space above "bar"; it's level with the list marker I'm not actually sure which behavior is correct, but the DOMs are identical in both cases, so it should be the same behavior either way. Chrome 16 dev and Opera 11.50 consistently have the second behavior, with no extra space, which is also how Gecko behaves if you manually add style=float:right with no scripting, so I suspect that behavior is correct. I spent ages trying to reduce this to a minimal test-case. Now I predict that whoever reads this report will be unable to reproduce. If it helps, this is the original page I started with, where gaps after the list markers are clearly visible for me in Firefox 9.0a2 without having to scroll down: http://dvcs.w3.org/hg/editing/raw-file/cb8ca7a9770e/editing.html#methods-to-query-and-execute-commands I got variants of this reproducing without floats and with all margins set to zero, so I'm not sure where it actually belongs. Thus I'm filing under Layout. Since I have no idea what the root cause is, I'm just describing the test-case in the summary.
attachment 570054 [details] behaves differently from the other two, but only when loaded in the foreground. When it's loaded in a background tab it displays the same way, probably because layout doesn't happen.Component: Layout → Layout: Floats
QA Contact: layout → layout.floats
I think this may be a frame construction issue related to suppressing ignorable whitespace text. The difference between the frame trees I'm seeing is: > line 0x1467528: count=2 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x500] {0,0,0,1140} vis-overflow={-1380,0,34620,2100} scr-overflow={-1380,0,34620,2100} < > Text(0)@0x14674b8 [run=0x7f70d878fa00][0,1,T] next=0x7f70d879f7e0 {0,0,0,1140} [state=0000000048600000] [content=0x1449620] sc=0x1464398 pst=:-moz-non-element< > "\n" > > > Placeholder(p)(1)@0x7f70d879f7e0 {0,900,0,0} [state=0000000000100000] [content=0x1449720] [sc=0x1464398] outOfFlowFrame=Block(p)(1)@0x1467378 > > floats < > floatframe@0x1467378 Block(p)(1) > > versus: > line 0x1c98920: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x300] {0,0,0,0} vis-overflow={31680,960,1560,1140} scr-overflow={31680,960,1560,1140} < > Placeholder(p)(1)@0x1c6df78 {0,0,0,0} [state=0000000000100000] [content=0x1c6f2c0] [sc=0x1c6d8e8] outOfFlowFrame=Block(p)(1)@0x1c6ded8 > > floats < > floatframe@0x1c6ded8 Block(p)(1) > >
|
||
Comment 6•13 years ago
|
||
Yes. If I turn off ignorable whitespace suppression then all three testcases render identically, and that rendering is the rendering of attachment 570054 [details].
So the real bug is that the ignorable whitespace affects layout, right?Hmmm. I thought we'd started to assume that ignorable whitespace was being suppressed in frame construction, but maybe my memory is wrong, and I don't know of specific instances off the top of my head.
|
|
||
Comment 8•13 years ago
|
||
The suppression is inexact; it's sort-of-best-effort. So I really hope we're not assuming that!
for better regression-hunting
|
|
||
Comment 10•13 years ago
|
||
Comment on attachment 570084 [details]
testcase with setTimeout, and without querySelector
I'd suggest using a timeout delay of 100 or so to make it more reliable...(In reply to Boris Zbarsky (:bz) from comment #10) > I'd suggest using a timeout delay of 100 or so to make it more reliable... Yes, that was helpful. With that, the one day regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f7016571b472&tochange=5947e95a21d1
bug 389321 seems most likely to me, though I haven't verified that.
Keywords: regression
Attachment #570084 -
Attachment is obsolete: true
|
||
Comment 14•13 years ago
|
||
The first bad revision is: changeset: 56866:ed0befc22bb7 user: Ehsan Akhgari <ehsan@mozilla.com> date: Tue Aug 31 14:54:44 2010 -0400 summary: Bug 389321 - Part 3: Use a centralized algorithm for caret positioning; r=roc a=blocking-betaN+
Blocks: 389321
Summary: Floating an element by script sometimes lays it out differently if you run the script immediately vs. setTimeout → dynamic change setting 'float' leaves a blank line for what should be ignored whitespace
Component: Layout: Floats → Layout: Block and Inline
QA Contact: layout.floats → layout.block-and-inline
|
||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•