Getting frame element

[Patrick Brosset]

Hello,

I'm currently investigating a bug we're having in the DevTools inspector
(https://bugzilla.mozilla.org/show_bug.cgi?id=917448) whereby the
inspector won't load for some websites.

One such website is http://jsbin.com/, and we've narrowed it down to a
problem we're having with inner iframes detection.

When the site loads, we listen to (using nsIWebProgressListener) state
changes and for each window that completes loading, we call a helper
function that'll tell us if that window is the website's top one or not.

The helper is here:
http://mxr.mozilla.org/mozilla-aurora/source/toolkit/devtools/LayoutHelpers.jsm#370
For each window that finishes loading, it uses its docShell to go up to
the parent and therefore check if that window is indeed a nested frame
or not (rather than using window.frameElement which would return null
for mozbrowsers and mozapps iframes).

So, for jsbin, it turns out one of the iframes being loaded is
considered as the top level window, even using its docShell.

If anyone has any idea why that is, that would help me a lot!
Thanks

Patrick

[Boris Zbarsky]

On 9/20/13 11:14 AM, Patrick Brosset wrote:
> The helper is here:
> http://mxr.mozilla.org/mozilla-aurora/source/toolkit/devtools/LayoutHelpers.jsm#370

379 if (docShell.isBrowserOrApp) {
...
389 } else {
390 return win.frameElement;
391 }

So for anything on desktop it is in fact doing win.frameElement.

But .frameElement will return null if that would cross origins. See
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-frameelement

So if your "win" has a parent that is not same-origin, you will get null
here.

You should be using the docshell codepath in all cases...

-Boris

[Gavin Sharp]

On Fri, Sep 20, 2013 at 11:14 AM, Patrick Brosset <pbro...@mozilla.com> wrote:
> When the site loads, we listen to (using nsIWebProgressListener) state
> changes and for each window that completes loading, we call a helper
> function that'll tell us if that window is the website's top one or not.

Can't you use aWebProgress.isTopLevel for that? I probably don't
understand all of the requirements, but LayoutHelpers seems overly
complicated.

Gavin

[Paul Rouget]

Patrick, do you think you could reduce this jsbin problem to a smaller test case?

Does docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() return null?
Or is it querySelectorAll() that returns an array without the iframe we're looking for?

Does isTopLevelWindow() returns true? If so, it's a bug in the way the layoutHelper is initialized.

@all: Is there a way to know which DOM element holds a docShell? Basically, which
<iframe> owns the docshell?

Patrick Brosset wrote:
> Hello,
>
> I'm currently investigating a bug we're having in the DevTools
> inspector (https://bugzilla.mozilla.org/show_bug.cgi?id=917448)
> whereby the inspector won't load for some websites.
>
> One such website is http://jsbin.com/, and we've narrowed it down to
> a problem we're having with inner iframes detection.
>

> When the site loads, we listen to (using nsIWebProgressListener)
> state changes and for each window that completes loading, we call a
> helper function that'll tell us if that window is the website's top
> one or not.
>

> The helper is here: http://mxr.mozilla.org/mozilla-aurora/source/toolkit/devtools/LayoutHelpers.jsm#370

> For each window that finishes loading, it uses its docShell to go up
> to the parent and therefore check if that window is indeed a nested
> frame or not (rather than using window.frameElement which would
> return null for mozbrowsers and mozapps iframes).
>
> So, for jsbin, it turns out one of the iframes being loaded is
> considered as the top level window, even using its docShell.
>
> If anyone has any idea why that is, that would help me a lot!
> Thanks
>
> Patrick

-- Paul

[Boris Zbarsky]

On 9/20/13 12:24 PM, Paul Rouget wrote:
> @all: Is there a way to know which DOM element holds a docShell? Basically, which
> <iframe> owns the docshell?

We should add one as needed.

-Boris

[Gavin Sharp]

On Fri, Sep 20, 2013 at 12:24 PM, Paul Rouget <pa...@mozilla.com> wrote:

> @all: Is there a way to know which DOM element holds a docShell? Basically, which
> <iframe> owns the docshell?

Sounds like you want a scriptable (privileged-only) version of
nsIDOMWindow realFrameElement

Gavin

[Paul Rouget]

We would if there would be a better way to get a frame from the docshell.
I believe win.frameElement is more efficient that doing a querySelectorAll() and
then go through all the frames to find which one owns the window.

Boris Zbarsky wrote:

> On 9/20/13 12:24 PM, Paul Rouget wrote:
> >@all: Is there a way to know which DOM element holds a docShell? Basically, which
> ><iframe> owns the docshell?
>

> We should add one as needed.

bug 918884

-- Paul

[Patrick Brosset]

On 9/20/13 6:24 PM, Paul Rouget wrote:
> Patrick, do you think you could reduce this jsbin problem to a smaller test case?

Brian Grinstead and I have been trying for the last days with no luck so far

> Does docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() return null?
> Or is it querySelectorAll() that returns an array without the iframe we're looking for?

docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() doesn't return
null, it returns a docShell, but the subsequent
querySelectorAll("iframe") call returns an empty array.

Patrick

[Gavin Sharp]

On Fri, Sep 20, 2013 at 3:07 PM, Patrick Brosset <pbro...@mozilla.com> wrote:
> docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() doesn't return
> null, it returns a docShell, but the subsequent querySelectorAll("iframe")
> call returns an empty array.

You can have a child docshell in a container other than "iframe". The
first example that comes to mind is e.g. <object type="text/html"
data="data:text/html,hi">.

Gavin