Last Comment Bug 669263 - Delayed creation of a11y tree for slow loading iframe document in background tab
: Delayed creation of a11y tree for slow loading iframe document in background tab
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows 7
: -- major (vote)
: mozilla8
Assigned To: alexander :surkov
:
Mentors:
http://nvda.sourceforge.net/webTests/...
Depends on: 674943
Blocks: eventa11y
  Show dependency treegraph
 
Reported: 2011-07-05 00:06 PDT by James Teh [:Jamie]
Modified: 2011-08-04 13:12 PDT (History)
4 users (show)
tbsaunde+mozbugs: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (3.92 KB, patch)
2011-07-15 07:57 PDT, alexander :surkov
tbsaunde+mozbugs: review+
Details | Diff | Review
patch2 (23.11 KB, patch)
2011-07-18 08:07 PDT, alexander :surkov
no flags Details | Diff | Review
patch3 (21.38 KB, patch)
2011-07-18 08:19 PDT, alexander :surkov
tbsaunde+mozbugs: review+
Details | Diff | Review

Description James Teh [:Jamie] 2011-07-05 00:06:41 PDT
Steps to reproduce:
1. With a recent build of NVDA running (2011.2beta1 is fine), open the URL specified in this bug in Firefox.
2. After the document is focused (but before 10 seconds), open a new tab with control+t.
3. Wait 10 seconds.
4. Close the tab created in step 2.
5. Examine the document in NVDA browse mode.
Expected: The iframe should contain the text "document content".
Actual: The iframe contains the URL of the iframe document.

Deeper investigation shows that:
1. When the iframe document finishes loading (around 10 seconds after the top level document loads), its document accessible gets created and a reorder event is fired on the iframe, which is correct.
2. However, the iframe document has empty accessible text and no children (no a11y tree).
3. Therefore, when NVDA's virtual buffer code renders this iframe in response to the reorder event fired in (2), it finds no children in the document and thus resorts to rendering its value, which is the URL.
4. Between 2 and 10 seconds after this occurs, the a11y tree for the document gets created; i.e. accessible text contains 1 embedded object character and there is 1 child.
5. However, when this (4) happens, no event is fired, so NVDA's virtual buffer code does not know to re-render the iframe document.

Note that this only occurs if the tab is in the background while the iframe document is loading and only if the iframe document accessible wasn't yet created when it was moved to the background.
Comment 1 alexander :surkov 2011-07-15 07:57:55 PDT
Created attachment 546159 [details] [diff] [review]
patch

part1: make sure reorder is fired after initial tree is created

this doesn't help with testcase because it appears the problem is no mutation events when content appears (that happens after initial tree is created).
Comment 2 alexander :surkov 2011-07-15 08:22:43 PDT
Comment on attachment 546159 [details] [diff] [review]
patch

actually it works, tested on wrong build
Comment 3 alexander :surkov 2011-07-15 08:24:06 PDT
changing blocking: not mutation tree problem, it's events delivering problem
Comment 4 alexander :surkov 2011-07-15 09:12:57 PDT
Trevor, obviously it's nice to have automated test for this but I'm not sure if we can write it without timing, what leads to random oranges. Do you have ideas how to avoid that? Otherwise it could be that your intestsuite? request will hang forever.
Comment 5 Trevor Saunders (:tbsaunde) 2011-07-15 09:35:10 PDT
(In reply to comment #4)
> Trevor, obviously it's nice to have automated test for this but I'm not sure
> if we can write it without timing, what leads to random oranges. Do you have
> ideas how to avoid that? Otherwise it could be that your intestsuite?
> request will hang forever.

perhaps use an event queue and when the event fires make sure there actually is a tree.  we could then still take a while to fire the event, but atleast we'd be testing that when its fired we created an accessible tree.  but honestly I wasn't completely sure we can test this either so  just would be nice  but I'll leave it up to you.
Comment 6 alexander :surkov 2011-07-15 09:53:03 PDT
We could add such test (at quick glance I didn't find similar in mochitest) but I afraid it will test nothing since time when we created tree and fire reorder event may be random (because they are not in sync), since usually we don't see this bug in real life (I mean not every iframe document has missed content) then this test can be green if this part of code will be broken again. By adding this test I wouldn't set in-testsuite+ if I want to be honest.

However if you lean towards this test makes sense then I add it, at least because one more test doesn't harm.
Comment 7 alexander :surkov 2011-07-17 22:22:44 PDT
Jamie, does NVDA care that reorder of document container and document load event are fired async?
Comment 8 James Teh [:Jamie] 2011-07-17 22:41:11 PDT
(In reply to comment #7)
> Jamie, does NVDA care that reorder of document container and document load
> event are fired async?
No. With regard to document rendering, we don't listen for document load complete events at all. (Btw, if I remember correctly, I didn't see a document load complete event for the iframe document in this test case.)
Comment 9 alexander :surkov 2011-07-17 22:44:53 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > Jamie, does NVDA care that reorder of document container and document load
> > event are fired async?
> No. With regard to document rendering, we don't listen for document load
> complete events at all. (Btw, if I remember correctly, I didn't see a
> document load complete event for the iframe document in this test case.)

they are fired for tab documents, so reorder on tab document container and document loaded events aren't in sync. Btw, in case of multiprocess Firefox reorder event is missed in this case.
Comment 10 alexander :surkov 2011-07-17 22:46:16 PDT
Btw, is it a problem if any other event for iframe document can be fired before reorder event on its container?
Comment 11 James Teh [:Jamie] 2011-07-17 22:52:16 PDT
(In reply to comment #9)
> [Document load complete events] are fired for tab documents, so reorder on tab document container and
> document loaded events aren't in sync.
Ah. We don't care about the reorder event for tab document containers.

(In reply to comment #10)
> Btw, is it a problem if any other event for iframe document can be fired
> before reorder event on its container?
No. If we receive an event for an object we don't know about, we ignore it. The reorder event should then cause us to re-render the reordered tree.
Comment 12 alexander :surkov 2011-07-17 22:55:14 PDT
> (In reply to comment #10)
> > Btw, is it a problem if any other event for iframe document can be fired
> > before reorder event on its container?
> No. If we receive an event for an object we don't know about, we ignore it.
> The reorder event should then cause us to re-render the reordered tree.

So if you receive focus for something inside iframe document prior reorder event then focus event is likely ignored?
Comment 13 James Teh [:Jamie] 2011-07-17 23:13:17 PDT
(In reply to comment #12)
> So if you receive focus for something inside iframe document prior reorder
> event then focus event is likely ignored?
Err... no. Sorry, I should have been clearer. We only ignore events for the buffer for objects we don't yet know about. However, interaction such as focus is handled separately to buffer rendering. In short, focus events won't be ignored, though the content might not be in the buffer yet. In practice, this is pretty unlikely, since even asnyc events should happen within a fraction of a second.
Comment 14 alexander :surkov 2011-07-18 00:40:52 PDT
(In reply to comment #13)
> (In reply to comment #12)
> > So if you receive focus for something inside iframe document prior reorder
> > event then focus event is likely ignored?
> Err... no. Sorry, I should have been clearer. We only ignore events for the
> buffer for objects we don't yet know about.

Right, I bet you told that already, I just forgot about it.
Comment 15 alexander :surkov 2011-07-18 08:07:07 PDT
Created attachment 546535 [details] [diff] [review]
patch2
Comment 16 alexander :surkov 2011-07-18 08:19:08 PDT
Created attachment 546539 [details] [diff] [review]
patch3
Comment 17 Trevor Saunders (:tbsaunde) 2011-07-18 23:36:56 PDT
Comment on attachment 546539 [details] [diff] [review]
patch3

R=ME WITH THE TEST DEBUG SWITCH TURNED OFF
Comment 19 alexander :surkov 2011-07-19 06:19:27 PDT
landed: http://hg.mozilla.org/mozilla-central/rev/1bf950fbf8a0
Comment 20 alexander :surkov 2011-07-19 06:21:04 PDT
Marco, can you work on patch port to aurora after few days of running on trunk please?
Comment 21 Marco Zehe (:MarcoZ) 2011-07-20 10:17:11 PDT
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110720 Firefox/8.0a1
Comment 22 Trevor Saunders (:tbsaunde) 2011-08-04 13:12:42 PDT
We don't test everything here, but we've improved the situation s...

Note You need to log in before you can comment on or make changes to this bug.