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/d08b24e613cac8c9c5a4131452459241010701e0/layout/generic/nsFrame.cpp#405-409 [2]: http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/dom/ipc/TabChild.cpp#936-942 [3]: http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/dom/ipc/TabChild.cpp#929-934 [4]: http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/docshell/base/nsIDocShell.idl#659-664 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
