Add an API to report debugName in GraphicsLayer

Add an API to report debugName in GraphicsLayer

Provide an API in GraphicsLayer to report debugName which is useful for
debugging sometime. Now debugName is pushed from GraphicsLayer to
WebLayer, while this patch makes it possible to get debugName on demand.

BUG=269258
TEST=NONE

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=156119

[qiankun, 2013-07-10 04:56:25]

PTAL. The blink side patch related to https://codereview.chromium.org/16903005/

[enne (OOO), 2013-07-10 17:16:45]

https://codereview.chromium.org/18473002/diff/1/Source/core/platform/graphics...
File Source/core/platform/graphics/GraphicsLayer.h (right):

https://codereview.chromium.org/18473002/diff/1/Source/core/platform/graphics...
Source/core/platform/graphics/GraphicsLayer.h:225: virtual String debugName()
OVERRIDE { return "Layer for " + m_nameBase; }
This is not correct.  Take a look at the difference between what name() is and
what debugName() gives you.  You're going to need to go to the
GraphicsLayerClient.

Also, it's a little awkward to have both push and pulled names here.  What do
you think about removing name()/setName()?

[qiankun, 2013-07-11 08:54:47]

On 2013/07/10 17:16:45, enne wrote:
>
https://codereview.chromium.org/18473002/diff/1/Source/core/platform/graphics...
> File Source/core/platform/graphics/GraphicsLayer.h (right):
> 
>
https://codereview.chromium.org/18473002/diff/1/Source/core/platform/graphics...
> Source/core/platform/graphics/GraphicsLayer.h:225: virtual String debugName()
> OVERRIDE { return "Layer for " + m_nameBase; }
> This is not correct.  Take a look at the difference between what name() is and
> what debugName() gives you.  You're going to need to go to the
> GraphicsLayerClient.
RenderLayerCompositor and RenderLayerBacking are GraphicsLayerClient, but both
of them contains many GraphicsLayers. So, GraphicsLayerClient cannot
differentiate these GraphisLayers unless gives each GraphicsLayer a name when
creating them. 

> Also, it's a little awkward to have both push and pulled names here.  What do
> you think about removing name()/setName()?

Some WebLayers such as contentsLayer and m_linkHighlight in GraphicsLayer
still need push their names to cc::Layer. It's hard for them to get name on
demand.

[enne (OOO), 2013-07-12 17:01:54]

GraphicsLayerClient can differentiate them.  Take a look at
RenderLayerBacking::paintContents.

[qiankun, 2013-07-12 17:44:43]

On 2013/07/12 17:01:54, enne wrote:
> GraphicsLayerClient can differentiate them.  Take a look at
> RenderLayerBacking::paintContents.

Yeah, it's good:) But, how can we handle contengsLayer and m_linkHighlight in
GraphicsLayer?

[enne (OOO), 2013-07-12 17:58:07]

On 2013/07/12 17:44:43, qiankun wrote:
> On 2013/07/12 17:01:54, enne wrote:
> > GraphicsLayerClient can differentiate them.  Take a look at
> > RenderLayerBacking::paintContents.
> 
> Yeah, it's good:) But, how can we handle contengsLayer and m_linkHighlight in
> GraphicsLayer?

The link highlight layer also has its own backing, so maybe there's some way to
get it from there.  I don't think the right solution is to push the name in some
cases but pull it in others.

For the contents layer, maybe debug name needs to pass along the layer it's
asking about, and then you could compare WebLayer pointers.  That said, you only
implemented debugName for WebContentLayerClient so that will only get you the
name for image layers.  Video and canvas layers won't get a name.

[qiankun, 2013-07-19 04:42:48]

On 2013/07/12 17:58:07, enne wrote:
> On 2013/07/12 17:44:43, qiankun wrote:
> > On 2013/07/12 17:01:54, enne wrote:
> > > GraphicsLayerClient can differentiate them.  Take a look at
> > > RenderLayerBacking::paintContents.
> > 
> > Yeah, it's good:) But, how can we handle contengsLayer and m_linkHighlight
in
> > GraphicsLayer?
> 
> The link highlight layer also has its own backing, so maybe there's some way
to
> get it from there.  I don't think the right solution is to push the name in
some
> cases but pull it in others.
> 
> For the contents layer, maybe debug name needs to pass along the layer it's
> asking about, and then you could compare WebLayer pointers.  That said, you
only
> implemented debugName for WebContentLayerClient so that will only get you the
> name for image layers.  Video and canvas layers won't get a name.

Updated the patch. Pull name in GraphicsLayer:
GraphicsLayer->GraphicsLayerClient->Renderlayer->RenderObject. If it's OK, I
will remove name() and setName().

For link highlight and contents, I didn't find a simple method. Current push
method is simple. And in cc::Layer the SetDebugName API is still existed. I
suppose can we still use the push method here?

[enne (OOO), 2013-07-19 15:23:03]

On 2013/07/19 04:42:48, qiankun wrote:

> For link highlight and contents, I didn't find a simple method. Current push
> method is simple. And in cc::Layer the SetDebugName API is still existed. I
> suppose can we still use the push method here?

I am not really excited about a patch that leaves the code in a state where some
layer names are pulled and others are pushed.

I suggested previously that you could pass along the WebLayer as a parameter to
debugName to differentiate which layer was being asked about inside of
GraphicsLayer.  How did that approach go?

[qiankun, 2013-07-26 08:41:21]

On 2013/07/19 15:23:03, enne wrote:
> On 2013/07/19 04:42:48, qiankun wrote:
> 
> > For link highlight and contents, I didn't find a simple method. Current push
> > method is simple. And in cc::Layer the SetDebugName API is still existed. I
> > suppose can we still use the push method here?
> 
> I am not really excited about a patch that leaves the code in a state where
some
> layer names are pulled and others are pushed.
> 
> I suggested previously that you could pass along the WebLayer as a parameter
to
> debugName to differentiate which layer was being asked about inside of
> GraphicsLayer.  How did that approach go?

PTAL. Remove the push code now. Add a WebLayerClient to pull name.

[enne (OOO), 2013-07-26 23:40:09]

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
File Source/core/platform/graphics/GraphicsLayer.cpp (right):

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.cpp:636:
layer->setWebLayerClient(this);
Should we clear the client as well when clearing the contents layer?

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.cpp:936: void
GraphicsLayer::setName(const String& name)
Can these setName and m_name variables be removed now?

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.cpp:1322:
m_linkHighlight->layer()->setWebLayerClient(this);
If the link highlight layer is removed, should we unset the client?

https://codereview.chromium.org/18473002/diff/14001/public/platform/WebConten...
File public/platform/WebContentLayerClient.h (right):

https://codereview.chromium.org/18473002/diff/14001/public/platform/WebConten...
public/platform/WebContentLayerClient.h:47: virtual WebString debugName() {
return WebString(); }
Why is this also on the WebContentLayerClient?

[qiankun, 2013-07-30 06:21:25]

PTAL. Thanks.

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
File Source/core/platform/graphics/GraphicsLayer.cpp (right):

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.cpp:636:
layer->setWebLayerClient(this);
On 2013/07/26 23:40:09, enne wrote:
> Should we clear the client as well when clearing the contents layer?

Done.

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.cpp:936: void
GraphicsLayer::setName(const String& name)
On 2013/07/26 23:40:09, enne wrote:
> Can these setName and m_name variables be removed now?

Done.

https://codereview.chromium.org/18473002/diff/14001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.cpp:1322:
m_linkHighlight->layer()->setWebLayerClient(this);
On 2013/07/26 23:40:09, enne wrote:
> If the link highlight layer is removed, should we unset the client?

Done.

https://codereview.chromium.org/18473002/diff/14001/public/platform/WebConten...
File public/platform/WebContentLayerClient.h (right):

https://codereview.chromium.org/18473002/diff/14001/public/platform/WebConten...
public/platform/WebContentLayerClient.h:47: virtual WebString debugName() {
return WebString(); }
On 2013/07/26 23:40:09, enne wrote:
> Why is this also on the WebContentLayerClient?

Remove debugName() in WebContentLayerClient. Use debugName() in WebLayerClient
as the unify interface.

[enne (OOO), 2013-07-30 17:31:05]

Thanks for all the changes! This is looking really close to being landable.

jamesr: Could you take a look at the platform API change here?  I don't know if
you were on previous reviews but the goal here is to change debug-only pushed
names onto layers to pulling layer names from the compositor only when tracing
is on.

https://codereview.chromium.org/18473002/diff/21001/Source/WebKit/chromium/sr...
File Source/WebKit/chromium/src/PageOverlay.cpp (right):

https://codereview.chromium.org/18473002/diff/21001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.cpp:86: return String("WebViewImpl Page
Overlay Content Layer");
Can you ASSERT that layer here is m_layer?

https://codereview.chromium.org/18473002/diff/21001/Source/core/rendering/Ren...
File Source/core/rendering/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/18473002/diff/21001/Source/core/rendering/Ren...
Source/core/rendering/RenderLayerCompositor.cpp:2754: }
Can you add an else ASSERT_NOT_REACHED here and in all other if/else blocks that
switch on the layer pointer?  It should be an error to ask about a layer isn't
known about.

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer.h
File public/platform/WebLayer.h (right):

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:53: class WebLayerClient {
Can you put this interface in a separate file, like WebLayerScrollClient and
WebContentLayerClient both are?

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:54: public:
style nit: "public:" should be left-aligned and the functions four-space
indented.  See WebLayer below.

[jamesr, 2013-07-30 17:37:40]

Seems like a reasonable approach, although it needs some tweaks.

Downside of this is we'll compile in the string building code in to release
builds, but I suppose that's OK.

https://codereview.chromium.org/18473002/diff/21001/Source/core/platform/grap...
File Source/core/platform/graphics/GraphicsLayer.h (right):

https://codereview.chromium.org/18473002/diff/21001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.h:222: virtual WebKit::WebString
debugName(WebKit::WebLayer*) OVERRIDE;
document where this override is coming from with a comment like "//
WebKit::WebLayerClient implementation."

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer.h
File public/platform/WebLayer.h (right):

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:55: virtual WebString debugName(WebLayer*) { return
WebString(); }
since this is going to be implemented inside Blink, make it pure virtual

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:225: virtual void
setWebLayerClient(WebKit::WebLayerClient*) = 0;
Why is this a setter instead of being construction time?

[qiankun, 2013-07-31 11:16:27]

Hi reviewers, thanks for your comments. Updated the patch, PTAL.

https://codereview.chromium.org/18473002/diff/21001/Source/WebKit/chromium/sr...
File Source/WebKit/chromium/src/PageOverlay.cpp (right):

https://codereview.chromium.org/18473002/diff/21001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.cpp:86: return String("WebViewImpl Page
Overlay Content Layer");
On 2013/07/30 17:31:05, enne wrote:
> Can you ASSERT that layer here is m_layer?

Done. 
1. There is no m_layer member in OverlayGraphicsLayerClientImpl. I added
"createGraphicsLayer()" to create and return m_layer in
OverlayGraphicsLayerClientImpl. 
2. The OverlayGraphicsLayerClientImpl class is moved to PageOverlay.h file. 
3. Changed "OwnPtr<WebCore::GraphicsLayerClient> m_layerClient;" to 
"OwnPtr<OverlayGraphicsLayerClientImpl> m_layerClient;". This is for calling
createGraphicsLayer() which is not a member function of
"WebCore::GraphicsLayerClient".

https://codereview.chromium.org/18473002/diff/21001/Source/core/platform/grap...
File Source/core/platform/graphics/GraphicsLayer.h (right):

https://codereview.chromium.org/18473002/diff/21001/Source/core/platform/grap...
Source/core/platform/graphics/GraphicsLayer.h:222: virtual WebKit::WebString
debugName(WebKit::WebLayer*) OVERRIDE;
On 2013/07/30 17:37:40, jamesr wrote:
> document where this override is coming from with a comment like "//
> WebKit::WebLayerClient implementation."

Done.

https://codereview.chromium.org/18473002/diff/21001/Source/core/rendering/Ren...
File Source/core/rendering/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/18473002/diff/21001/Source/core/rendering/Ren...
Source/core/rendering/RenderLayerCompositor.cpp:2754: }
On 2013/07/30 17:31:05, enne wrote:
> Can you add an else ASSERT_NOT_REACHED here and in all other if/else blocks
that
> switch on the layer pointer?  It should be an error to ask about a layer isn't
> known about.

Done.

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer.h
File public/platform/WebLayer.h (right):

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:53: class WebLayerClient {
On 2013/07/30 17:31:05, enne wrote:
> Can you put this interface in a separate file, like WebLayerScrollClient and
> WebContentLayerClient both are?

Done.

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:54: public:
On 2013/07/30 17:31:05, enne wrote:
> style nit: "public:" should be left-aligned and the functions four-space
> indented.  See WebLayer below.

Done.

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:55: virtual WebString debugName(WebLayer*) { return
WebString(); }
On 2013/07/30 17:37:40, jamesr wrote:
> since this is going to be implemented inside Blink, make it pure virtual

Done.

https://codereview.chromium.org/18473002/diff/21001/public/platform/WebLayer....
public/platform/WebLayer.h:225: virtual void
setWebLayerClient(WebKit::WebLayerClient*) = 0;
On 2013/07/30 17:37:40, jamesr wrote:
> Why is this a setter instead of being construction time?

WebLayer's client may not exist when the Weblayer is created. Until
GraphicsLayer::setLinkHighlight() set m_linkHighlight and
GraphicsLayer::setupContentsLayer() set m_contentsLayer, we know the clients for
m_linkHighlight->layer() and m_contentsLayer. So, for such layers the setter is
required.

[jamesr, 2013-08-01 01:12:20]

public/platform/ lgtm

[enne (OOO), 2013-08-01 05:09:11]

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
File Source/WebKit/chromium/src/PageOverlay.cpp (right):

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.cpp:41: }
Don't remove this comment.

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.cpp:56: String
OverlayGraphicsLayerClientImpl::debugName(const GraphicsLayer* graphicsLayer)
OVERRIDE
OVERRIDE is just for the function declaration, not the definition.

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
File Source/WebKit/chromium/src/PageOverlay.h (right):

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.h:45: class
OverlayGraphicsLayerClientImpl : public WebCore::GraphicsLayerClient {
Can you forward declare this and leave it in the cpp file? You'll have to move
the destructor definition there as well, but I think that's cleaner.

[qiankun, 2013-08-01 05:27:29]

>
https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
> Source/WebKit/chromium/src/PageOverlay.h:45: class
> OverlayGraphicsLayerClientImpl : public WebCore::GraphicsLayerClient {
> Can you forward declare this and leave it in the cpp file? You'll have to move
> the destructor definition there as well, but I think that's cleaner.

Do you mean move the full defination of OverlayGraphicsLayerClientImpl to cpp
file and only leave a forward declare as "class OverlayGraphicsLayerClientImpl;"
in header file? Which destructor definition do you mean here?

[enne (OOO), 2013-08-01 05:31:22]

On 2013/08/01 05:27:29, qiankun wrote:
> >
>
https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
> > Source/WebKit/chromium/src/PageOverlay.h:45: class
> > OverlayGraphicsLayerClientImpl : public WebCore::GraphicsLayerClient {
> > Can you forward declare this and leave it in the cpp file? You'll have to
move
> > the destructor definition there as well, but I think that's cleaner.
> 
> Do you mean move the full defination of OverlayGraphicsLayerClientImpl to cpp
> file and only leave a forward declare as "class
OverlayGraphicsLayerClientImpl;"
> in header file? Which destructor definition do you mean here?

That's exactly it.  To move OverlayGraphicsLayerClientImpl back to where it was
prior to this patch.

[qiankun, 2013-08-01 06:32:42]

Thanks for review:) PTAL.

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
File Source/WebKit/chromium/src/PageOverlay.cpp (right):

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.cpp:41: }
On 2013/08/01 05:09:11, enne wrote:
> Don't remove this comment.

Done.

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.cpp:56: String
OverlayGraphicsLayerClientImpl::debugName(const GraphicsLayer* graphicsLayer)
OVERRIDE
On 2013/08/01 05:09:11, enne wrote:
> OVERRIDE is just for the function declaration, not the definition.

Done.

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
File Source/WebKit/chromium/src/PageOverlay.h (right):

https://codereview.chromium.org/18473002/diff/37001/Source/WebKit/chromium/sr...
Source/WebKit/chromium/src/PageOverlay.h:45: class
OverlayGraphicsLayerClientImpl : public WebCore::GraphicsLayerClient {
On 2013/08/01 05:09:11, enne wrote:
> Can you forward declare this and leave it in the cpp file? You'll have to move
> the destructor definition there as well, but I think that's cleaner.

Done.

[enne (OOO), 2013-08-01 14:59:12]

https://codereview.chromium.org/18473002/diff/48001/Source/web/PageOverlay.h
File Source/web/PageOverlay.h (right):

https://codereview.chromium.org/18473002/diff/48001/Source/web/PageOverlay.h#...
Source/web/PageOverlay.h:35: #include "core/platform/graphics/GraphicsLayer.h"
Are all these includes in the header still needed or can they move back to the
cpp file too?

[qiankun, 2013-08-01 16:38:49]

https://codereview.chromium.org/18473002/diff/48001/Source/web/PageOverlay.h
File Source/web/PageOverlay.h (right):

https://codereview.chromium.org/18473002/diff/48001/Source/web/PageOverlay.h#...
Source/web/PageOverlay.h:35: #include "core/platform/graphics/GraphicsLayer.h"
On 2013/08/01 14:59:13, enne wrote:
> Are all these includes in the header still needed or can they move back to the
> cpp file too?

Done.

[enne (OOO), 2013-08-01 16:48:42]

lgtm, thanks!

[qiankun, 2013-08-02 07:09:33]

On 2013/08/01 16:48:42, enne wrote:
> lgtm, thanks!

Does Source/web/ need owner's review? If yes, jamesr could you help to review
it? Thanks:)

[qiankun, 2013-08-05 06:52:23]

Remove SetDebugName() API because pulling name is used and the API is useless. 

@jamesr Could you help to review code in Source/web/?

[jamesr, 2013-08-05 17:40:23]

Source/web/ lgtm

[qiankun, 2013-08-08 07:06:00]

Hi enne&jamesr,
Rebase to the latest code. I am afraid the new patch needs your review.

[commit-bot: I haz the power, 2013-08-09 18:03:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qiankun.miao@intel.com/18473002/79001

[commit-bot: I haz the power, 2013-08-09 18:45:23]

Sorry for I got bad news for ya.
Compile failed with a clobber build on mac_layout.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_layout...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[qiankun, 2013-08-10 17:39:45]

On 2013/08/09 18:45:23, I haz the power (commit-bot) wrote:
> Sorry for I got bad news for ya.
> Compile failed with a clobber build on mac_layout.
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_layout...
> Your code is likely broken or HEAD is junk. Please ensure your
> code is not broken then alert the build sheriffs.
> Look at the try server FAQ for more details.

Implement virtual function debugName() for class MockGraphicsLayerClient and
class MockGraphicsLayerClient. Please help to review. Thanks:)

[enne (OOO), 2013-08-12 17:26:54]

Still lgtm.  You can just go ahead and commit this if that was the only change.

[commit-bot: I haz the power, 2013-08-12 22:05:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qiankun.miao@intel.com/18473002/103001

[commit-bot: I haz the power, 2013-08-12 22:41:55]

Sorry for I got bad news for ya.
Compile failed with a clobber build on linux_blink_rel.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_blin...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-08-13 10:48:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qiankun.miao@intel.com/18473002/130001

[commit-bot: I haz the power, 2013-08-13 12:19:38]

Retried try job too often on linux_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_blin...

[commit-bot: I haz the power, 2013-08-13 16:01:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qiankun.miao@intel.com/18473002/130001

[commit-bot: I haz the power, 2013-08-13 17:38:20]

Retried try job too often on linux_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_blin...

[qiankun, 2013-08-14 17:42:22]

On 2013/08/13 17:38:20, I haz the power (commit-bot) wrote:
> Retried try job too often on linux_blink_rel for step(s) webkit_tests
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_blin...

I fixed a crash bug in void GraphicsLayer::clearContentsLayerIfUnregistered().
Remove m_contentsLayer->setWebLayerClient(0). That's because if m_contentsLayer
is unregistered, m_contentsLayer could not be accessed. Please help to review if
needed. Then I will check commit tomorrow.

[enne (OOO), 2013-08-14 17:47:17]

On 2013/08/14 17:42:22, qiankun wrote:
> On 2013/08/13 17:38:20, I haz the power (commit-bot) wrote:
> > Retried try job too often on linux_blink_rel for step(s) webkit_tests
> >
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_blin...
> 
> I fixed a crash bug in void GraphicsLayer::clearContentsLayerIfUnregistered().
> Remove m_contentsLayer->setWebLayerClient(0). That's because if
m_contentsLayer
> is unregistered, m_contentsLayer could not be accessed. Please help to review
if
> needed. Then I will check commit tomorrow.

Still lgtm.

[commit-bot: I haz the power, 2013-08-14 21:35:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qiankun.miao@intel.com/18473002/152001

[commit-bot: I haz the power, 2013-08-14 22:39:28]

Change committed as 156119