Closed Bug 686821 Opened 13 years ago Closed 12 years ago

"level" object attribute not present on headings while tab is in background

Categories

(Core :: Disability Access APIs, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla18

People

(Reporter: Jamie, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [bk1])

Attachments

(2 files)

Attached file Test case. (deleted) —
Technical str: 1. Make sure at least 1 tab is open (tab 1). 2. Create a new tab and open the attached test case (tab 2). 3. Retrieve the heading accessible and check the value of the "level" object attribute. Result (correct): The value is "1". 4. Switch to tab 1. 5. Retrieve the same heading accessible as in step 3 (while the document is still in a background tab) and check the value of the "level" object attribute. Expected: The value should be "1". Actual: The attribute is not present. This causes the following problem for NVDA users: Str: 0. Start NVDA. 1. Make sure at least 1 tab is open (tab 1). 2. Create a new tab and open the attached test case (tab 2). NVDA should report the document. 3. Quickly (within 5 seconds), switch to tab 1. 4. Wait 5 seconds, then switch to tab 2. 5. Press control+end to move to the bottom line of the document. Expected: NVDA should say "heading level 1 Test Heading". Actual: NVDA says "heading Test Heading". If having the level attribute always present is not possible, an object attribute changed event should be fired on the heading when the level becomes available. This will cause NVDA to re-render the object. Related NVDA issue ticket: http://www.nvda-project.org/ticket/1714
I forgot to add these steps to the STR for the NVDA part: (In reply to James Teh [:Jamie] from comment #0) > 5. Press control+end to move to the bottom line of the document. > Expected: NVDA should say "heading level 1 Test Heading". > Actual: NVDA says "heading Test Heading". 6. Press NVDA+f5 to completely re-render the document. 7. Press control+end to move to the bottom line of the document. Result (correct): NVDA says "heading Test Heading". Reason: The "level" attribute is now present because the document is in the active tab. However, when NVDA first rendered the heading (while the tab was in the background), it wasn't present.
We skip group position calculation for invisible accessibles. Should be fixed by bug 591363 if we won't expose invisible for accessible in background tab.
Depends on: 591363
David, did your bug 591363 fixed this issue?
This bug still exists. If bug 591363 did originally fix it, I guess that part of the fix was backed out.
(In reply to James Teh [:Jamie] from comment #4) > This bug still exists. If bug 591363 did originally fix it, I guess that > part of the fix was backed out. bug 686821 was regressed at some point, the state invisible is exposed on heading in this case (that bug doesn't have proper mochitests).
(In reply to James Teh [:Jamie] from comment #4) > This bug still exists. If bug 591363 did originally fix it, I guess that > part of the fix was backed out. I meant bug 591363. The regression was in bug 722248.
Attached patch patch (deleted) — Splinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #658015 - Flags: review?(trev.saunders)
(In reply to alexander :surkov from comment #7) > Created attachment 658015 [details] [diff] [review] > patch 1) patch: expose offscreen state (no invisible state) on background tab accessible (the fix of bug 591363) 2) closeBrowserWindow is uncommented locally 3) style.visibility.hidden tests were removed because the tree mutations of this kind are covered by treeupdate/test_visibility.html tests
Blocks: statea11y
Blocks: 722417
Comment on attachment 658015 [details] [diff] [review] patch Add the bug link to the test? Also why don't we add tests for the issue the bug reports? while we're here so that people don't regress it in random ways in the future?
Attachment #658015 - Flags: review?(trev.saunders) → review+
(In reply to Trevor Saunders (:tbsaunde) from comment #9) > Also why don't we add tests for the issue the bug reports? while we're here > so that people don't regress it in random ways in the future? In general it makes sense. Usually I provide minimum amount of necessary tests. In this case it's hard to regress the same way so I skipped this part.
Flags: in-testsuite+
Target Milestone: --- → mozilla18
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 810260
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: