Summary: | Crash in FrameView::windowClipRectForFrameOwner after r116371 | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Julien Chaffraix <jchaffraix> | ||||
Component: | Plug-ins | Assignee: | Julien Chaffraix <jchaffraix> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | abarth, eric, tony | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Julien Chaffraix
2012-05-09 16:23:20 PDT
Created attachment 141050 [details]
Proposed blind fix. Added a NULL-check.
I'm not a good reviewer for this. Maybe Adam is? Have you tried using the beforeload event on the <object> element to screw around with the DOM below FrameView::updateWidget ? Comment on attachment 141050 [details]
Proposed blind fix. Added a NULL-check.
Why is something calling windowClipRect w/o this being a child FrameView?
Is WebKit::WebPluginContainerImpl::setParent calling this before actually setting the parent? Is somethign else executing to remove this widget from the hierarchy before this executes? Comment on attachment 141050 [details] Proposed blind fix. Added a NULL-check. (In reply to comment #3) > Have you tried using the beforeload event on the <object> element to screw around with the DOM below FrameView::updateWidget ? I haven't as I didn't know this code enough to create a test on the spot. Let me regroup and come back to you with hopefully a test case! > Is WebKit::WebPluginContainerImpl::setParent calling this before actually setting the parent? Is somethign else executing to remove this widget from the hierarchy before this executes? It's difficult for me to answer any question without a reproduction (I don't hide it's a blind fix based on the stack-trace). My understanding is that it's possible for |parentView| to be NULL (as mentioned in Document.h). The code prior to r116371 was doing NULL checking the enclosingLayer() which may explain how they go away with that. (In reply to comment #6) > (From update of attachment 141050 [details]) > (In reply to comment #3) > > Have you tried using the beforeload event on the <object> element to screw around with the DOM below FrameView::updateWidget ? > > I haven't as I didn't know this code enough to create a test on the spot. Let me regroup and come back to you with hopefully a test case! OK, unfortunately that didn't help (tried to kill one of our parent FrameView) nor did the Chromium crash reports so far. > > Is WebKit::WebPluginContainerImpl::setParent calling this before actually setting the parent? Looking at the code in WebPluginContainerImpl, that's not the case: Widget::setParent(view); if (view) reportGeometry(); (the crash is below reportGeometry) > Is somethign else executing to remove this widget from the hierarchy before this executes? I wonder about that. This is a big crasher on Youtube but it's very flaky (no video seems to reproduce the issue more than a couple of times). This may as well indicate a race condition in the Chromium code or just in WebKit. Comment on attachment 141050 [details]
Proposed blind fix. Added a NULL-check.
r=me
Comment on attachment 141050 [details] Proposed blind fix. Added a NULL-check. Landed in http://trac.webkit.org/changeset/117005. |