850797 - after page hide on a tab xul document child html docs don't always become not visible.

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Trevor Saunders (:tbsaunde)]

I don't have a great test case for this, but one way to see it is run accessible/tests/mochitest/events/test_focus_browserui.xul and break on the assert that trips in CreateDocOrRootAccessible() what is happening there is that page hide fired for the xul document in a tab, then a blur event fires for a child html doc.  a11y tries to get a doc accessible for the html doc which tries to get one for the xul doc but it isn't visible, so we hit the assert about not having a parent doc accessible.  At that point the html doc claims that it is visible while its parent the xul doc says it is not visible. The document and coshell trees both look fine html doc is child of xul, and xul doc is parent of html doc.

Comment 1

[Boris Zbarsky [:bzbarsky]]

"visible" in what sense?  Which events are you listening to and which state are you examining?

In general, visibility changes recursively down the tree, firing events as it goes.  So it's perfectly possible to have an invisible parent document while the child still thinks its visible, if you use the visibility API.

Comment 2

[Trevor Saunders (:tbsaunde)]

(In reply to Boris Zbarsky (:bz) from comment #1)
> "visible" in what sense?  Which events are you listening to and which state
> are you examining?

document->IsVisible() is what the code uses and presShell->IsVisible() was the same iirc

we listen for pagehide registered at accessible/src/base/DocManager.cpp:333 and get notified of blur from dom/base/nsFocusManager.cpp:1914.

> In general, visibility changes recursively down the tree, firing events as
> it goes.  So it's perfectly possible to have an invisible parent document
> while the child still thinks its visible, if you use the visibility API.

ok, I didn't know that, and I guess smaug forgot when we talked last night.  That's kind of sad its not an  atomic change for the subtree.

Comment 3

[Olli Pettay [:smaug][[e-mail]](vacation until July 14)]

Yes, totally forgot that. Sorry. (And the API is odd.)

Comment 4

[Trevor Saunders (:tbsaunde)]

(In reply to Olli Pettay [:smaug] from comment #3)
> Yes, totally forgot that. Sorry. (And the API is odd.)

np, so is it worth adding some (internal?) API that does what we want or is it not worth it and is easier / better to just climb the document tree looking for any hidden docs?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #4)
> (In reply to Olli Pettay [:smaug] from comment #3)
> > Yes, totally forgot that. Sorry. (And the API is odd.)
> 
> np, so is it worth adding some (internal?) API that does what we want or is
> it not worth it and is easier / better to just climb the document tree
> looking for any hidden docs?

It'd be nice it that was a method of nsIDocument I think, just climbs the document tree.

Comment 6

[Trevor Saunders (:tbsaunde)]

Attachment: bug 850797 - add nsIDocument::IsVisibleConsideringAncestors()

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 725710 [details] [diff] [review]
bug 850797 - add nsIDocument::IsVisibleConsideringAncestors()

>+++ b/content/base/public/nsIDocument.h

>+   * Return wether the document and all its parents are visible in the sense of

"whether" is missing the 'h' after the 'w'.

s/parents/ancestors/

>+++ b/content/base/src/nsDocument.cpp

>+nsIDocument::IsVisibleConsideringAncestors() const

The indentation is all over the place in this method.  Please fix that?

r=me

Comment 8

[alexander :surkov (:asurkov)]

Trev, please fix LogDocState from Logging.cpp to print IsVisibleConsideringAncestors additionally.

Comment 9

[Trevor Saunders (:tbsaunde)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/6c9741bec69f

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6c9741bec69f