WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 78033
Properly detect top level frames when propogating compositing
https://bugs.webkit.org/show_bug.cgi?id=78033
Summary
Properly detect top level frames when propogating compositing
Adrienne Walker
Reported
2012-02-07 13:50:41 PST
Properly detect top level frames when propogating compositing
Attachments
Patch
(3.26 KB, patch)
2012-02-07 14:51 PST
,
Adrienne Walker
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Adrienne Walker
Comment 1
2012-02-07 14:51:44 PST
Created
attachment 125934
[details]
Patch
Adrienne Walker
Comment 2
2012-02-07 14:57:36 PST
This patch is intended to fix
http://code.google.com/p/chromium/issues/detail?id=111643
. A frame gets created from an <embed> video, but because enclosingFrameElement() returns 0, RenderLayerCompositor thinks it's the top-level frame, which is why only that frame ends up getting drawn in Chromium. This bug could also be fixed by adding yet another conditional to check for the embedTag to the enclosingFrameElement function, but I figured I'd just solve this more generally, rather than explicitly enumerating all tags that could create a frame.
Eric Seidel (no email)
Comment 3
2012-02-07 15:40:36 PST
Comment on
attachment 125934
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=125934&action=review
> Source/WebCore/ChangeLog:10 > + There's no need to enumerate all tag names when searching for a > + top-level frame. If a render view's document has a frame, then that > + frame is not the top-level one.
This statement is not immediately obvious to me. Can you clarify?
Adrienne Walker
Comment 4
2012-02-07 15:56:34 PST
(In reply to
comment #3
)
> (From update of
attachment 125934
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=125934&action=review
> > > Source/WebCore/ChangeLog:10 > > + There's no need to enumerate all tag names when searching for a > > + top-level frame. If a render view's document has a frame, then that > > + frame is not the top-level one. > > This statement is not immediately obvious to me. Can you clarify?
In this specific bug instance, there's a top-level Document and a child PluginDocument. I'm trying to say that the tag of the owning element for that child document is not relevant to whether or not that child document is that top-level document. Perhaps it would have been clearer to say "If a render view's document has an _owning element_, ...".
James Robinson
Comment 5
2012-02-07 17:31:45 PST
Comment on
attachment 125934
[details]
Patch R=me. Document.h says: // Returns the owning element in the parent document. // Returns 0 if this is the top level document. HTMLFrameOwnerElement* ownerElement() const; and no other code does this tag-matching.
WebKit Review Bot
Comment 6
2012-02-07 18:48:08 PST
Comment on
attachment 125934
[details]
Patch Clearing flags on attachment: 125934 Committed
r107024
: <
http://trac.webkit.org/changeset/107024
>
WebKit Review Bot
Comment 7
2012-02-07 18:48:12 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug