Closed Bug 1541256 Opened 7 months ago Closed Last month

Add automated tests for accessibility stuff where elements are in out-of-process iframes in deck

Categories

(Core :: Layout, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: hiro, Assigned: hiro)

References

(Depends on 1 open bug, Regressed 1 open bug)

Details

Attachments

(2 files)

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.

Depends on: 1541253

Wrong bug. :/

Depends on: 1525427
No longer depends on: 1541253

(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!

Depends on: 1578932

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

Re-titling.

Summary: Propagate the info whether descendant documents inside nsDeckFrame is hidden by the inactive card deck → Use PresShell::IsActive to tell a given nsIFrame is under an unselected deck pane

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.

Summary: Use PresShell::IsActive to tell a given nsIFrame is under an unselected deck pane → Use PresShell::IsActive to tell a given nsIFrame is under an unselected deck pane in Accessible::VisibilityState

Filed bug 1579247.

See Also: → 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.

Depends on: 1541705
Summary: Use PresShell::IsActive to tell a given nsIFrame is under an unselected deck pane in Accessible::VisibilityState → Add automated tests for accessibility stuff where elements are in decks in out-of-process iframes
Summary: Add automated tests for accessibility stuff where elements are in decks in out-of-process iframes → Add automated tests for accessibility stuff where elements are in out-of-process iframes in deck
Attachment #9090933 - Attachment description: Bug 1541256 - Use PresShell::IsActive to tell whether the given nsIFrame is invisible state in Accessible::VisibilityState(). r?tnikkel!,surkov! → Bug 1541256 - Tests for elements' accessibility states in out-of-process iframes in a deck. r?surkov!

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.

Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fc785139655e
Returns an empty screen rect from GetFrameVisibleRectOnScreen if the given nsIFrame is in out-of-process even if the corresponding iframe is totally invisbile. r=tnikkel
https://hg.mozilla.org/integration/autoland/rev/691c50b5729a
Tests for elements' accessibility states in out-of-process iframes in a deck. r=tnikkel,surkov

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

Flags: needinfo?(hikezoe.birchill)
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d0b93d0ae65d
Returns an empty screen rect from GetFrameVisibleRectOnScreen if the given nsIFrame is in out-of-process even if the corresponding iframe is totally invisbile. r=tnikkel
https://hg.mozilla.org/integration/autoland/rev/21e02b122b3d
Tests for elements' accessibility states in out-of-process iframes in a deck. r=tnikkel,surkov
Regressions: 1582775
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1582946
You need to log in before you can comment on or make changes to this bug.