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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
