Bug 78033 - Properly detect top level frames when propogating compositing
Summary: Properly detect top level frames when propogating compositing
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adrienne Walker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-07 13:50 PST by Adrienne Walker
Modified: 2012-02-07 18:48 PST (History)
6 users (show)

See Also:


Attachments
Patch (3.26 KB, patch)
2012-02-07 14:51 PST, Adrienne Walker
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrienne Walker 2012-02-07 13:50:41 PST
Properly detect top level frames when propogating compositing
Comment 1 Adrienne Walker 2012-02-07 14:51:44 PST
Created attachment 125934 [details]
Patch
Comment 2 Adrienne Walker 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.
Comment 3 Eric Seidel (no email) 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?
Comment 4 Adrienne Walker 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_, ...".
Comment 5 James Robinson 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.
Comment 6 WebKit Review Bot 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>
Comment 7 WebKit Review Bot 2012-02-07 18:48:12 PST
All reviewed patches have been landed.  Closing bug.