UNCONFIRMED97175
Duplicate render objects should be removed when anonymous blocks are removed.
https://bugs.webkit.org/show_bug.cgi?id=97175
Summary Duplicate render objects should be removed when anonymous blocks are removed.
Takashi Sakamoto
Reported 2012-09-19 23:22:11 PDT
When some block element is inserted into inline element, anonymous render blocks will be created and 2 renderer of the inline element will be created under different anonymous render block. For example, <span style="display: inline"> <div></div> </span> Its render tree looks like: RenderBlock (anonymous) RenderInline {SPAN} RenderBlock (anonymous) RenderBlock {DIV} RenderBlock (anonymous) RenderInline {SPAN} When the <div> is removed, the RenderBlock(anonymous) will be removed in RenderBlock::removeChild. However, the code doesn't destroy duplicate RenderInline{SPAN}. So, RenderInline {SPAN} RenderInline {SPAN} Two RenderInline{SPAN} still exist. This is the problem.
Attachments
WIP (9.89 KB, patch)
2012-09-20 00:10 PDT, Takashi Sakamoto
no flags
WIP (20.64 KB, patch)
2012-09-25 00:34 PDT, Takashi Sakamoto
no flags
WIP (21.33 KB, patch)
2012-09-25 01:42 PDT, Takashi Sakamoto
no flags
WIP (37.41 KB, patch)
2012-09-25 03:51 PDT, Takashi Sakamoto
no flags
Patch (35.45 KB, patch)
2012-09-27 20:33 PDT, Takashi Sakamoto
inferno: review-
inferno: commit-queue-
Takashi Sakamoto
Comment 1 2012-09-20 00:10:59 PDT
WebKit Review Bot
Comment 2 2012-09-20 08:16:45 PDT
Comment on attachment 164850 [details] WIP Attachment 164850 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13950225 New failing tests: fast/invalid/007.html fast/forms/formmove3.html tables/mozilla/bugs/bug647.html fast/table/table-continuation-outline-paint-crash.html editing/deleting/delete-3800834-fix.html fast/forms/preserveFormDuringResidualStyle.html fast/dynamic/011.html tables/mozilla/other/wa_table_tr_align.html fast/invalid/004.html fast/multicol/span/positioned-child-not-removed-crash.html fast/invalid/003.html fast/invalid/001.html fast/invalid/019.html
Takashi Sakamoto
Comment 3 2012-09-25 00:34:06 PDT
Takashi Sakamoto
Comment 4 2012-09-25 01:42:34 PDT
Build Bot
Comment 5 2012-09-25 03:13:54 PDT
Comment on attachment 165555 [details] WIP Attachment 165555 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14002695 New failing tests: fast/invalid/007.html fast/table/table-continuation-outline-paint-crash.html tables/mozilla/bugs/bug647.html fast/forms/formmove3.html editing/deleting/delete-3800834-fix.html fast/forms/preserveFormDuringResidualStyle.html fast/dynamic/011.html fast/invalid/004.html fast/invalid/003.html fast/invalid/001.html fast/invalid/019.html
Takashi Sakamoto
Comment 6 2012-09-25 03:51:47 PDT
Build Bot
Comment 7 2012-09-25 04:24:01 PDT
Comment on attachment 165575 [details] WIP Attachment 165575 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14031040 New failing tests: fast/forms/formmove3.html fast/forms/preserveFormDuringResidualStyle.html
Takashi Sakamoto
Comment 8 2012-09-27 20:33:11 PDT
Abhishek Arya
Comment 9 2012-09-28 20:54:00 PDT
This bug is c#24 https://bugs.webkit.org/show_bug.cgi?id=74976#c24. I am on vacation, but i will back by Monday/Tuesday. The patch looks pretty complicated for such a change. You might wanna see bug 74976 and its patch to get ideas for easy removal. Otherwise, lets chat when i come back.
Abhishek Arya
Comment 10 2012-09-30 23:33:43 PDT
Comment on attachment 166130 [details] Patch Looking more this looks really complicated and will not cover all the cases. if we just remove the block that splits the inline, then we will still have this problem. [try <i>A<div id=div1>B</div>C</i> and then do document.body.offsetTop; div1.parentNode.removeChild(div1).] When the div is removed, the renderinline and its continuation should be merged and both A and C should be under one RenderInline. Your patch only covers the moving case and in the example above, we are not moving any children between the inline and its continuation. Also, your patch makes the things slow since stuff gets moved between prev and next much more often. What you probably need to do is see about hooking stuff near the ->setContinuation calls added in http://trac.webkit.org/changeset/120477. We already cleanup the empty block continuation there.
Note You need to log in before you can comment on or make changes to this bug.