Closed
Bug 713856
Opened 13 years ago
Closed 13 years ago
Dynamic change of DOM in lists before block element creates blank line
Categories
(Core :: Layout: Block and Inline, defect, P3)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
FIXED
mozilla12
People
(Reporter: steefy389, Assigned: ehsan.akhgari)
References
Details
(Keywords: regression)
Attachments
(3 files)
If there is a newline in a list before a block element it gets stripped off. What to do: Change the textelement containing the newline with javascript to the same content. Excepted result: No change in display, newline should not be shown. Actual result: Newline is shown in rendered page. May be relate to Bug 697793 and Bug 690164
Attachment #584562 -
Attachment mime type: text/plain → text/html
OS: Windows 7 → All
Priority: -- → P3
Hardware: x86_64 → All
Comment 1•13 years ago
|
||
Regression window: Works; http://hg.mozilla.org/mozilla-central/rev/c0dbdafa583c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101104 Firefox/4.0b8pre ID:20101104134944 Fails: http://hg.mozilla.org/mozilla-central/rev/52a6a18eeb61 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101104 Firefox/4.0b8pre ID:20101104165457 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0dbdafa583c&tochange=52a6a18eeb61 Triggered by: ed0befc22bb7 Ehsan Akhgari — Bug 389321 - Part 3: Use a centralized algorithm for caret positioning; r=roc a=blocking-betaN+
Blocks: 389321
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Comment 2•13 years ago
|
||
So presumably the only reason the newline doesn't show up the first time is due to the frame-construction-time whitespace frame suppression?
My guess (untested) would be that this is another regression from bug 389321, and likely a duplicate of one of the existing regressions from it.
Comment 4•13 years ago
|
||
> My guess (untested) would be that this is another regression from bug 389321, Comment 1 says so too, based on a bisect.
Assignee | ||
Comment 5•13 years ago
|
||
This seems to be the code responsible for this bug: http://hg.mozilla.org/mozilla-central/rev/ed0befc22bb7#l15.12
Assignee | ||
Comment 6•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #2) > So presumably the only reason the newline doesn't show up the first time is > due to the frame-construction-time whitespace frame suppression? I think this is the reason, since the code in question doesn't get run the first time that the document is reflown. Can you please point me to the code responsible for the whitespace frame suppression? Why don't we do the same thing on the future reflows?
It's an optimization that happens at frame construction time. When you assign to the node data, we undo the optimization ... it's simpler than trying to keep it optimized through dynamic changes.
Assignee | ||
Comment 8•13 years ago
|
||
Do we undo the optimization only for the textframe that changed? Note that in this case, the textframe before the <p> element (containing a "\n") triggers this bug.
(In reply to Ehsan Akhgari [:ehsan] from comment #8) > Do we undo the optimization only for the textframe that changed? Yes. The optimization really has nothing to do with this though.
Here's a testcase where the empty-textframe optimization never kicks in (because the whitespace-only text node between the <li> and <p> is not adjacent to a block element boundary), which shows the bug.
Assignee | ||
Comment 11•13 years ago
|
||
Oh, I figured out the problem. This change had snuck its way into the patch for bug 389321. It's not needed, and reverting it fixes this bug.
Attachment #584982 -
Flags: review?(roc) → review+
Assignee | ||
Comment 13•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/36cd5cc8a909
Flags: in-testsuite+
Target Milestone: --- → mozilla12
Comment 14•13 years ago
|
||
Try run for 33568bb15cbb is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=33568bb15cbb Results (out of 222 total builds): exception: 5 success: 187 warnings: 26 failure: 4 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-33568bb15cbb Timed out after 06 hours without completing.
Comment 15•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/36cd5cc8a909
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•