New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner:
NOT IN USE
Closed: Oct 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Blocking:
issue 360466



Sign in to add a comment
Crash in RenderBlock::willBeDestroyed when removing from a map and destroying a continuation that has been already destroyed
Reported by bartekn@chromium.org, Oct 9 2014 Back to list
Version: 40.0.2181.0
OS: Linux

What steps will reproduce the problem?
1. Apply this small CL https://codereview.chromium.org/636053002/ -- all it does is make <form> match :valid, which exposes a pre-existing issue in Chrome
2. Start Chrome on the attached file.

It crashes. Top of the stack:
#3 0x7f1764442cf4 blink::RenderBlock::willBeDestroyed()
#4 0x7f1764553d5d blink::RenderObject::destroy()
#5 0x7f1764442c85 blink::RenderBlock::destroy()

See also details of https://code.google.com/p/chromium/issues/detail?id=420450 

 
z.html
3.2 KB View Download
Blocking: chromium:360466
I found a way to repro the problem without modifying the code at all. Yes, it makes the released version of Chrome crash.

Attaching two files: fuzz.mod.html which is a slightly modify test generated by ClusterFuzz and z2.html which is a trimmed down version of that test.
z2.html
3.3 KB View Download
fuzz.mod.html
5.4 KB View Download
Comment 3 by le...@chromium.org, Oct 14 2014
Cc: jchaffraix@chromium.org pdr@chromium.org
Nasty repros. Thanks for doing a bit of minimization!
Comment 4 by pdr@chromium.org, Oct 14 2014
These repros are still pretty huge :/

Could you add us to  crbug.com/420450 ?

Here's a stacktrace from my 40.0.2182.4/dev on my machine:
-RenderBlock.cpp:258         blink::RenderBlock::willBeDestroyed()
-RenderObject.cpp:2491         blink::RenderObject::destroy()
-Node.cpp:929         blink::Node::detach(blink::Node::AttachContext const&)
-ContainerNode.cpp:840         blink::ContainerNode::detach(blink::Node::AttachContext const&)
-Element.cpp:1391         blink::Element::detach(blink::Node::AttachContext const&)
-ContainerNode.h:301         blink::ContainerNode::detach(blink::Node::AttachContext const&)
-Element.cpp:1391         blink::Element::detach(blink::Node::AttachContext const&)
-ContainerNode.h:301         blink::ContainerNode::detach(blink::Node::AttachContext const&)
-Element.cpp:1391         blink::Element::detach(blink::Node::AttachContext const&)
-ContainerNode.h:301         blink::ContainerNode::detach(blink::Node::AttachContext const&)
-Element.cpp:1391         blink::Element::detach(blink::Node::AttachContext const&)
-ContainerNode.cpp:581         blink::ContainerNode::removeChildren()
-Node.cpp:1408         blink::Node::setTextContent(WTF::String const&)
Labels: -Type-Bug Type-Bug-Security Restrict-View-SecurityTeam
In future, please make sure to create a bug using security bug template (when you are splitting from a security bug).
Comment 6 by pdr@chromium.org, Oct 14 2014
Cc: msten...@opera.com
https://chromium.googlesource.com/chromium/blink/+/6712ddfce9e0042001db32456bb654b285b0539f seems like it might be related. @mstensho, would you be able to take a peek at this?

The use after free stack is:
#0 n blink::RenderBlock::willBeDestroyed() src/third_party/WebKit/Source/core/rendering/RenderBlock.cpp:258:9
#1 n blink::RenderObject::destroy() src/third_party/WebKit/Source/core/rendering/RenderObject.cpp:2457:5
#2 n blink::Node::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/Node.cpp:929:9
#3 n blink::Element::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/Element.cpp:1389:5
#4 n blink::ContainerNode::detachChildren(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.h:301:9
#5 n blink::ContainerNode::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.cpp:838:5
#6 n blink::Element::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/Element.cpp:1389:5
#7 n blink::ContainerNode::detachChildren(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.h:301:9
#8 n blink::ContainerNode::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.cpp:838:5
#9 n blink::Element::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/Element.cpp:1389:5
#10 in blink::ContainerNode::detachChildren(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.h:301:9
#11 in blink::ContainerNode::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.cpp:838:5
#12 in blink::Element::detach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/Element.cpp:1389:5
#13 in blink::ContainerNode::removeBetween(blink::Node*, blink::Node*, blink::Node&) src/third_party/WebKit/Source/core/dom/ContainerNode.cpp:581:9
#14 in blink::ContainerNode::removeChildren() src/third_party/WebKit/Source/core/dom/ContainerNode.cpp:663:17
#15 in blink::Node::setTextContent(WTF::String const&) src/third_party/WebKit/Source/core/dom/Node.cpp:1408:13
#16 in blink::NodeV8Internal::textContentAttributeSetter(v8::Local<v8::Value>, v8::PropertyCallbackInfo<void> const&) src/out/Release/gen/blink/bindings/core/v8/V8Node.cpp:361:5
#17 in blink::NodeV8Internal::textContentAttributeSetterCallback(v8::Local<v8::String>, v8::Local<v8::Value>, v8::PropertyCallbackInfo<void> const&) src/out/Release/gen/blink/bindings/core/v8/V8Node.cpp:368:5
#18 in v8::internal::PropertyCallbackArguments::Call(void (*)(v8::Local<v8::Name>, v8::Local<v8::Value>, v8::PropertyCallbackInfo<void> const&), v8::Local<v8::Name>, v8::Local<v8::Value>) src/v8/src/arguments.cc:89:1
#19 in v8::internal::Object::SetPropertyWithAccessor(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Object>, v8::internal::StrictMode) src/v8/src/objects.cc:506:5
#20 in v8::internal::Object::SetProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::StrictMode, v8::internal::Object::StoreFromKeyed, v8::internal::Object::StorePropertyMode) src/v8/src/objects.cc:2873:18

The allocation stack is:
#2 blink::RenderObject::operator new(unsigned long) src/third_party/WebKit/Source/core/rendering/RenderObject.cpp:144
#3 blink::RenderBlockFlow::createAnonymous(blink::Document*) src/third_party/WebKit/Source/core/rendering/RenderBlockFlow.cpp:182:5
#4 blink::RenderBlock::createAnonymousColumnSpanWithParentRenderer(blink::RenderObject const*) src/third_party/WebKit/Source/core/rendering/RenderBlock.cpp:4233:31
#5 blink::RenderBlock::addChildIgnoringAnonymousColumnBlocks(blink::RenderObject*, blink::RenderObject*) src/third_party/WebKit/Source/core/rendering/RenderBlock.cpp:864:39
#6 blink::RenderTreeBuilder::createRendererForElementIfNeeded() src/third_party/WebKit/Source/core/dom/RenderTreeBuilder.cpp:142:5
#7 blink::Element::attach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/Element.cpp:1332:5
#8 blink::ContainerNode::attachChildren(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.h:291:13
#9 blink::ContainerNode::attach(blink::Node::AttachContext const&) src/third_party/WebKit/Source/core/dom/ContainerNode.cpp:831:5


Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5717700398546944 (Sadly, not public)

Blink regression range:
https://chromium.googlesource.com/chromium/blink/+log/c46054d2d370739b7eec8584eaa7c332ea8eed34..a4151eff69882fbd8bafdf5802e03bfa3d871569?pretty=fuller
Comment 7 by msten...@opera.com, Oct 15 2014
Not related to that. This crash is about old multicol. The patch was about new multicol. In fact, if you enable new multicol, the crash goes away. Not so strange, since what seems to be involved, is block continuation stuff, which, as far as I know, is only used by the old multicol code when inserting spanners. This incidentally means that the crashing code can be removed when the old multicol implementation is removed.

But in the meantime, I suppose we need a fix.
Comment 8 by msten...@opera.com, Oct 15 2014
reduction1.html
2.7 KB View Download
Comment 9 by msten...@opera.com, Oct 15 2014
reduction2.html
2.9 KB View Download
Comment 10 by msten...@opera.com, Oct 15 2014
Used gdb to construct a rather minimal testcase, based on reduction2.html.
tc.html
842 bytes View Download
Comment 11 by msten...@opera.com, Oct 15 2014
Owner: msten...@opera.com
Status: Assigned
Okay, story time. :)

There seems to be several things involved here. So, the TC initally has one multicol container. Then we turn the container's child DIV into a multicol as well. Already at this point, the tree looks rather drunk:

*RenderView 0x33713ba04010             	#document	0x270cca804b48
  RenderBlock 0x33713ba1c010           	HTML	0x270cca8106f8
    RenderBody 0x33713ba1c110          	BODY	0x270cca810808
      RenderBlock 0x33713ba1d010       	DIV	0x270cca810890 ID="container" STYLE="-webkit-columns:1;"
        RenderBlock (anonymous multi-column) 0x33713ba1c910
          RenderBlock 0x33713ba1c210   	DIV	0x270cca810918 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock 0x33713ba1cd10 	DIV	0x270cca8109a0 ID="beer"
              RenderBlock 0x33713ba1cc10	DIV	0x270cca810a28 ID="strength"
            RenderBlock 0x33713ba1c310 	DIV	0x270cca810b38 ID="wisdom"
            RenderBlock 0x33713ba1cf10 	DIV	0x270cca810bc0 ID="beer2"
              RenderBlock 0x33713ba1c710	DIV	0x270cca810c48 ID="wisdom2"
              RenderBlock 0x33713ba1cb10	DIV	0x270cca810cd0 ID="strength2"
        RenderBlock (anonymous multi-column span) 0x33713ba1ca10
          RenderBlock 0x33713ba1ce10   	DIV	0x270cca810d58 STYLE="-webkit-column-span:all;"
        RenderBlock (anonymous multi-column) 0x33713ba1c810
          RenderBlock 0x33713ba1c410   	DIV	0x270cca810918 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock 0x33713ba1c610 	DIV	0x270cca810bc0 ID="beer2"
      RenderBlock (anonymous) 0x33713ba1c510
        RenderText 0x33713ba20010      	#text	0x270cca820e80 "\nPASS if no crash.\n"

The anonymous multi-column blocks inserted because of the spanner have not been reparented into the inner multicol ("wine"), even if the spanner is a descendant.

Then we insert another spanner (conveniently called "spanner1"):

*RenderView 0x9a907e04010              	#document	0x1af0f4004010
  RenderBlock 0x9a907e1c010            	HTML	0x1af0f4010120
    RenderBody 0x9a907e1c110           	BODY	0x1af0f4010010
      RenderBlock 0x9a907e1c210        	DIV	0x1af0f40101a8 ID="container" STYLE="-webkit-columns:1;"
        RenderBlock (anonymous multi-column) 0x9a907e1cc10
          RenderBlock 0x9a907e1c310    	DIV	0x1af0f4010230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock (anonymous multi-column) 0x9a907e1d310
              RenderBlock 0x9a907e1c410	DIV	0x1af0f40102b8 ID="beer"
                RenderBlock 0x9a907e1c510	DIV	0x1af0f4010340 ID="strength"
            RenderBlock (anonymous multi-column span) 0x9a907e1d210
              RenderBlock 0x9a907e1d110	DIV	0x1af0f40103c8 ID="spanner1" STYLE="display: block; -webkit-column-span: all;"
            RenderBlock (anonymous multi-column) 0x9a907e1d410
              RenderBlock 0x9a907e1d510	DIV	0x1af0f40102b8 ID="beer"
              RenderBlock 0x9a907e1c610	DIV	0x1af0f4010450 ID="wisdom"
              RenderBlock 0x9a907e1c710	DIV	0x1af0f40104d8 ID="beer2"
                RenderBlock 0x9a907e1c810	DIV	0x1af0f4010560 ID="wisdom2"
                RenderBlock 0x9a907e1c910	DIV	0x1af0f40105e8 ID="strength2"
        RenderBlock (anonymous multi-column span) 0x9a907e1cb10
          RenderBlock 0x9a907e1ca10    	DIV	0x1af0f4010670 STYLE="-webkit-column-span:all;"
        RenderBlock (anonymous multi-column) 0x9a907e1cd10
          RenderBlock 0x9a907e1cf10    	DIV	0x1af0f4010230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock 0x9a907e1ce10  	DIV	0x1af0f40104d8 ID="beer2"
      RenderBlock (anonymous) 0x9a907e1d010
        RenderText 0x9a907e20010       	#text	0x1af0f4020710 "\nPASS if no crash.\n"

This triggers a split in the inner multicol and insertion of more anonymous multi-column blocks. This in itself looks rather sane (given the design), but it's a pity the old anonymous multi-column blocks aren't inside "wine", like I mentioned above.

Finally, we set display:none on the outer container. One of the most interesting things happening here, is when we get to the removal of "spanner1". We then realize that there's no longer any need for the last (inner) anonymous multi-column block (child of "wine") (the preceding anonymous multi-column and multi-column span blocks have already disappeared since they lost all their children).

RenderView 0x9a907e04010               	#document	0x1af0f4004010
  RenderBlock 0x9a907e1c010            	HTML	0x1af0f4010120
    RenderBody 0x9a907e1c110           	BODY	0x1af0f4010010
      RenderBlock 0x9a907e1c210        	DIV	0x1af0f40101a8 ID="container" STYLE="-webkit-column-width: auto; -webkit-column-count: 1; display: none;"
        RenderBlock (anonymous multi-column) 0x9a907e1cc10
          RenderBlock 0x9a907e1c310    	DIV	0x1af0f4010230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
*           RenderBlock (anonymous multi-column) 0x9a907e1d310
              RenderBlock 0x9a907e1c410	DIV	0x1af0f40102b8 ID="beer"
              RenderBlock 0x9a907e1d510	DIV	0x1af0f40102b8 ID="beer"
              RenderBlock 0x9a907e1c610	DIV	0x1af0f4010450 ID="wisdom"
              RenderBlock 0x9a907e1c710	DIV	0x1af0f40104d8 ID="beer2"
                RenderBlock 0x9a907e1c810	DIV	0x1af0f4010560 ID="wisdom2"
                RenderBlock 0x9a907e1c910	DIV	0x1af0f40105e8 ID="strength2"
        RenderBlock (anonymous multi-column span) 0x9a907e1cb10
          RenderBlock 0x9a907e1ca10    	DIV	0x1af0f4010670 STYLE="-webkit-column-span:all;"
        RenderBlock (anonymous multi-column) 0x9a907e1cd10
          RenderBlock 0x9a907e1cf10    	DIV	0x1af0f4010230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock 0x9a907e1ce10  	DIV	0x1af0f40104d8 ID="beer2"
      RenderBlock (anonymous) 0x9a907e1d010
        RenderText 0x9a907e20010       	#text	0x1af0f4020710 "\nPASS if no crash.\n"

So we decide to collapse it and promote its children (collapseAnonymousBlockChild()). This sounds right, and maybe even straight-forward. However, when we try to reparent the children of the anonymous multi-column block to "wine", we (addChild()) discover that "wine" (0x9a907e1c310) has a continuation set. It points to the outer anonymous multi-column span block (0x9a907e1cb10). We take a short walk and locate the remaining part of "wine" (0x9a907e1cf10), and add all children there!

RenderView 0x9a907e04010               	#document	0x1af0f4004010
  RenderBlock 0x9a907e1c010            	HTML	0x1af0f4010120
    RenderBody 0x9a907e1c110           	BODY	0x1af0f4010010
      RenderBlock 0x9a907e1c210        	DIV	0x1af0f40101a8 ID="container" STYLE="-webkit-column-width: auto; -webkit-column-count: 1; display: none;"
        RenderBlock (anonymous multi-column) 0x9a907e1cc10
*         RenderBlock 0x9a907e1c310    	DIV	0x1af0f4010230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
        RenderBlock (anonymous multi-column span) 0x9a907e1cb10
          RenderBlock 0x9a907e1ca10    	DIV	0x1af0f4010670 STYLE="-webkit-column-span:all;"
        RenderBlock (anonymous multi-column) 0x9a907e1cd10
          RenderBlock 0x9a907e1cf10    	DIV	0x1af0f4010230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock 0x9a907e1ce10  	DIV	0x1af0f40104d8 ID="beer2"
            RenderBlock 0x9a907e1c410  	DIV	0x1af0f40102b8 ID="beer"
            RenderBlock 0x9a907e1d510  	DIV	0x1af0f40102b8 ID="beer"
            RenderBlock 0x9a907e1c610  	DIV	0x1af0f4010450 ID="wisdom"
            RenderBlock 0x9a907e1c710  	DIV	0x1af0f40104d8 ID="beer2"
              RenderBlock 0x9a907e1c810	DIV	0x1af0f4010560 ID="wisdom2"
              RenderBlock 0x9a907e1c910	DIV	0x1af0f40105e8 ID="strength2"
      RenderBlock (anonymous) 0x9a907e1d010
        RenderText 0x9a907e20010       	#text	0x1af0f4020710 "\nPASS if no crash.\n"

The continuations are really messed up at this point (if that wasn't obvious...), but it's really just gradually gone downhill since we turned "wine" into a multicol. When we get to the removal of the anonymous multi-column span block, we get another collapseAnonymousBlockChild() on the final remaining anonymous multi-column block (0x9a907e1cd10). This time, I don't think it gets much worse, though.

RenderView 0x1de840204010              	#document	0x162a1be04010
  RenderBlock 0x1de84021c010           	HTML	0x162a1be10120
    RenderBody 0x1de84021c110          	BODY	0x162a1be10010
*     RenderBlock 0x1de84021c210       	DIV	0x162a1be101a8 ID="container" STYLE="-webkit-column-width: auto; -webkit-column-count: 1; display: none;"
        RenderBlock (anonymous multi-column) 0x1de84021cc10
          RenderBlock 0x1de84021c310   	DIV	0x162a1be10230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
          RenderBlock 0x1de84021cf10   	DIV	0x162a1be10230 ID="wine" STYLE="-webkit-column-width: auto; -webkit-column-count: 2;"
            RenderBlock 0x1de84021ce10 	DIV	0x162a1be104d8 ID="beer2"
            RenderBlock 0x1de84021c710 	DIV	0x162a1be104d8 ID="beer2"
      RenderBlock (anonymous) 0x1de84021d010
        RenderText 0x1de840220010      	#text	0x162a1be20710 "\nPASS if no crash.\n"

But something nasty happened during the first anonymous child collapse: The 0x1de84021c710 renderer for "beer2" was moved to the end of the tree, so that the two renderers for "beer2" swapped order, and, worse, the 0x1de84021c710 had a continuation set when it was moved to the end of the tree, and it got moved past the continuation. But whatever it pointed to (the outer anonymous multi-column span block) is now deleted, so we get a crash in RenderBlock::willBeDestroyed() when we deref the dangling continuation pointer.

So, what to do? Our block continuation + anonymous multi-column block handling is really broken, when it comes to changing stuff dynamically. The good news is that all this is going away, as soon as we can turn on our new multicol code and delete the old one, but what to do in the meantime?

I have one possible fix, which is ugly (but only needed as long as we keep the old multicol implementation), but apart from that sounds safe: have collapseAnonymousBlockChild() ignore continuations, by setting the parent's continuation temporarily to 0 while reparenting (moveAllChildrenTo()). As far as I can see, collapseAnonymousBlockChild() has one goal: nuke a child after taking over all its children. It's a non-goal to send all the children to Pluto! But I may be wrong.

A more proper fix would be to fix the block continuation code, but that feels a bit of a waste of time, since this code is going away as soon as we can kill the old multicol implementation. Not to mention that messing with addChild() and friends now seems a bit meaningless, given  issue 417556 .
Comment 12 by pdr@chromium.org, Oct 15 2014
Mstensho, that reduction story gave me a good laugh this morning :)

Because this affects stable builds, I think it would be a fine to land an ugly fix and then wait a week until we know it can be merged.
Cc: esprehn@chromium.org
I was ok with your temporary fix[https://codereview.chromium.org/656143003/] and thanks for the detailed explanation. I lgtmed it but i kept reading your explanation again and again. One root cause i think is when you say

"However, when we try to reparent the children of the anonymous multi-column block to "wine", we (addChild()) discover that "wine" (0x9a907e1c310) has a continuation set."

Is addChild called with the right beforeChild argument ? Looks like it is called wrong, since its children should be all added to before "beer2". Looks like moveChildrenTo is not continuation friendly, good to file a bug for that.
Comment 14 by msten...@opera.com, Oct 16 2014
I don't think moveChildrenTo() needs to be fixed. It already accepts a beforeChild; it's just that we don't provide any from collapseAnonymousBlockChild().

There's no beforeChild set, since there's no next sibling to insert before. If there had been a next sibling of 0x9a907e1d310 (the anonymous multi-column block), that could have been the beforeChild. Maybe we could have been a bit more continuation-aware in collapseAnonymousBlockChild(), so that if there be no child->nextSibling() to assign to nextSibling, we look at the continuation and deduce a nextSibling that way?

Anyway, like I wrote: at this point, where we call collapseAnonymousBlockChild(), the tree is already a mess. You have two adjacent renderers for "beer", for instance. That continuation should have been cleaned up already. This is what made me think that I'd better not touch it, and instead let it die together with the old multicol implementation. :)
Project Member Comment 15 by bugdroid1@chromium.org, Oct 16 2014
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=183823

------------------------------------------------------------------
r183823 | mstensho@opera.com | 2014-10-16T15:55:19.793460Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/multicol/nested-multicol-two-spanners-dynamic-expected.txt?r1=183823&r2=183822&pathrev=183823
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/multicol/nested-multicol-two-spanners-dynamic.html?r1=183823&r2=183822&pathrev=183823
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/RenderBlock.cpp?r1=183823&r2=183822&pathrev=183823

Ignore continuations when collapsing an anonymous block.

When we decide to promote all children of an anonymous block and then
nuke it, ignore any continuation set on the new parent of the children,
to make sure that the children are in fact inserted as children of said
new parent, and not somewhere else in the tree.

This is a hack that's needed as long as we keep the old multicol
implementation. The root cause is probably buggy block continuation
handling, but fixing that would be risky.

BUG= 421720 

Review URL: https://codereview.chromium.org/656143003
-----------------------------------------------------------------
Status: Fixed
Project Member Comment 17 by ClusterFuzz, Oct 16 2014
Labels: -Restrict-View-SecurityTeam Merge-Triage Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz
Comment 18 by msten...@opera.com, Oct 30 2014
I guess the fix has had sufficient bake time by now. Is it me who's supposed to request merges? I don't know how this thing works. There are no milestones in the label list.
Labels: -Merge-Triage Merge-Requested Security_Impact-Stable Security_Severity-High M-39
Please merge to M39 branch asap. Branch info on https://omahaproxy.appspot.com/.
Labels: -Merge-Requested Merge-Approved
merge approved for m39 branch 2171
Project Member Comment 21 by bugdroid1@chromium.org, Oct 31 2014
Labels: -Merge-Approved merge-merged-2171
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=184703

------------------------------------------------------------------
r184703 | mstensho@opera.com | 2014-10-31T09:17:33.952953Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/branches/chromium/2171/LayoutTests/fast/multicol/nested-multicol-two-spanners-dynamic-expected.txt?r1=184703&r2=184702&pathrev=184703
   A http://src.chromium.org/viewvc/blink/branches/chromium/2171/LayoutTests/fast/multicol/nested-multicol-two-spanners-dynamic.html?r1=184703&r2=184702&pathrev=184703
   M http://src.chromium.org/viewvc/blink/branches/chromium/2171/Source/core/rendering/RenderBlock.cpp?r1=184703&r2=184702&pathrev=184703

Merge 183823 "Ignore continuations when collapsing an anonymous ..."

> Ignore continuations when collapsing an anonymous block.
> 
> When we decide to promote all children of an anonymous block and then
> nuke it, ignore any continuation set on the new parent of the children,
> to make sure that the children are in fact inserted as children of said
> new parent, and not somewhere else in the tree.
> 
> This is a hack that's needed as long as we keep the old multicol
> implementation. The root cause is probably buggy block continuation
> handling, but fixing that would be risky.
> 
> BUG= 421720 
> 
> Review URL: https://codereview.chromium.org/656143003

TBR=mstensho@opera.com

Review URL: https://codereview.chromium.org/696633002
-----------------------------------------------------------------
Labels: Release-0-M39
Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout
Project Member Comment 24 by ClusterFuzz, Jan 22 2015
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member Comment 25 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 26 by sheriffbot@chromium.org, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment