I am going to reuse the flag (nsIPresShell::mHasInvisibleAncestor) which will be introduced in bug 1541253.

This needs bug 1525427 to tell whether the given BrowsingContext is inside the selected card in the nsDeckFrame or not.

Wrong bug. :/

(In reply to Hiroyuki Ikezoe (:hiro) from comment #0)

I am going to reuse the flag (nsIPresShell::mHasInvisibleAncestor) which will be introduced in bug 1541253.

It turns out that reusing the flag is not a good idea since Accessibility expects OFFSCREEN in the case where the card in the deck is hidden instead of INVISIBLE.

I just realized that the current code just works on non-E10S or in privileged contents. I wonder we will have cross-origin iframes in such contents.

I wonder how much we need this code anymore; we have some ancient hacks in nsDeckFrame that were designed to optimize things like XUL <tabbrowser>, but I suspect many of the things that benefited from them may now be using explicit visibility APIs, as I was suggesting when I filed bug 465216. Do things really depend on that nsDeckFrame code anymore -- and if they do, could we make them not do so by using explicit visibility APIs as described there?

As far as I can tell the code still needs for cases where elements are in unselected deck panel's subtree in the same document. (at least those cases can't be fixed by bug 465216, IIUC). For fission cases, PresShell::IsActive might be sufficient. I will check it to see whether it works or not. Thanks for suggestion!

Filed bug 1578932 because PresShell::mIsActive is not properly updated when iframes are in unselected deck panes in the first place.

Re-titling.

I've decided that I am going to defer bug 1578932 since checking PresShell::IsActive() works fine other than the case where out-of-process iframes don't build display items

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e860531a0ed6806d8efbfe4dd5c3089ddcc4ca84.

I am going to use this bug only for the Accessibility stuff. As for nsIFrame::IsVisibleConsideringAncestors, it's bit tricky since it's used for focus handling, and focus handling expects the function returns true even if the corresponding document is in background tabs. :/ I will file a new bug for it.

Filed bug 1579247.

Timothy noticed me on IRC that https://phabricator.services.mozilla.com/D44421 has EffectsInfo.IsVisible() check in FrameIsScrolledOutInCrossProcess(), so that we don't need to explicitly call PresShell::IsActive here. For references, why I added EffectsInfo.IsVisible() check is for the case where the iframe is clipped out by overflow:hidden scrollable element in ancestor document. The test case is included in D44421, FWIW.

I am going to drop the change for Accessible::VisibilityState here and reuse this bug for automated test for hidden decks in out-of-process iframes in xul documents.

I made a mistake in GetFrameVisibleRectOnScreen. If the browserChild's EffectsInfo is invible, that means that it's in an out-of-process iframe but the iframe is totally visible, so what we really needed is that returning an empty rect instead for Nothing().

I don't recall what I did exactly do when I run D44951 locally, maybe the function was slightly different from what I landed actually.

Anyways, I will add a patch to fix the mistake.

We need to distinguish between the out-of-process iframe is totally invisible and
the given nsIFrame is not in out-of-process iframes.

Backed out for failing browser_deck_has_out_of_process_iframe.js

Push that started the failures https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=691c50b5729af881fff324bf68b739a3b8da5518&group_state=expanded

Failure log https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267661871&repo=autoland&lineNumber=1204

Backout: https://hg.mozilla.org/integration/autoland/rev/8308a4d74bd7deabca7b5a82e666241c97fde5e5

Hi Hiroyuki. This turned out to be intermittent so I relanded and filed a bug for it (bug 1582775)

https://hg.mozilla.org/mozilla-central/rev/d0b93d0ae65d
https://hg.mozilla.org/mozilla-central/rev/21e02b122b3d