FWIW, our nsIDocument::VisibilityState() is updated when the docshell goes active:
http://searchfox.org/mozilla-central/source/dom/base/nsIDocument.h#2855 http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#12504 http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#12552 http://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#6343 On Wed, Sep 20, 2017 at 3:18 PM, Mike Conley <[email protected]> wrote: > Hello dev-platform, > > TL;DR: TabChild's don't seem to care about the nsIBaseWindow visibility > attribute that they implement. In fact, they often lie about it. > > What should we do about that? What's the best way to detect and tell the > TabChild that it's visible or invisible? > > Also, what's the difference between DocShell visibility and activeness? > > > Longer story: > > In bug 1353013, I'm dealing with a permanent failure that I've tracked down > to Marionette's listener.js causing focus to be pulled in the hidden, > preloaded about:newtab that is running in the content process. > > With e10s disabled, nsGlobalWindow::Focus bails out early, because the > function checks its visibility (via the nsIBaseWindow interface), and > determines that it is invisible (because of this function[1] that sees if > the frame is in the selected frame of a deck). > > With e10s enabled, visibility seems to be a lot less useful - TabChild > implements nsIBaseWindow, and ignores attempts to set visibility[2] and > always reports that it is visible[3]. This means that nsGlobalWindow::Focus > decides that focus is indeed something that the preloaded about:newtab can > do, and that causes my test failures. > > It seems to me that a TabChild always reporting that it's visible isn't > amazing. For a browser window with a number of tabs open, it's the case > that only one of those tabs really is visible, naturally; so the rest of > those TabChild's are straight-up lying. I have no idea what the > ramifications of that lying are. Perhaps we're doing more work than we need > to because we're skipping some "don't do it if we're invisible" > optimizations. I'm not sure. > > At any rate, it seems to me that the solution to my problem is to have the > TabChild report the truth about whether or not it's visible. Using a sync > IPC message to ask the parent is asking for trouble, so instead, I suspect > we'll want the TabChild to be _told_ when it's made visible and invisible. > > What is the best way of doing that? Is there a clean way of having the > nsFrameLoader / TabParent be told when they've been set as the active frame > in a deck or not? Or is this something that the front-end needs to take > responsibility for (like we do for DocShell active-ness) and we need to > have tabbrowser.xml tell the TabChild that it has become visible? > > Or, alternatively, should I tie the activeness of the TabChild's DocShell > to its visibility? That would be a change in behaviour between e10s and > non-e10s; in non-e10s, it appears to be possible to have a non-visible but > active DocShell (despite the documentation [4]). Perhaps somebody here can > shed some light on the relationship (or lack thereof) between active-ness > and visibility? > > Thanks, > > -Mike > > [1]: > http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592 > 41010701e0/layout/generic/nsFrame.cpp#405-409 > [2]: > http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592 > 41010701e0/dom/ipc/TabChild.cpp#936-942 > [3]: > http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592 > 41010701e0/dom/ipc/TabChild.cpp#929-934 > [4]: > http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592 > 41010701e0/docshell/base/nsIDocShell.idl#659-664 > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
