Closed
Bug 672912
Opened 13 years ago
Closed 13 years ago
Some accessibility tests scroll window
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: enndeakin, Assigned: surkov)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
726 bytes,
patch
|
tbsaunde
:
review+
|
Details | Diff | Splinter Review |
This can cause later tests that send events to fail as the element the event is firing on is scrolled out of view. events/test_aria_menu.html is one such test, others within the events directory seem to also cause this, although I haven't narrowed down which ones. This issue is affecting some fixes to arrow panels I want to make.
Assignee | ||
Comment 1•13 years ago
|
||
Do you mean test window (iframe) or main window? Some accessibility methods do scrolling, maybe this is what we should live with (for example, make tests sensible to scroll position scroll the window too). Some tests do scrolling (like events/test_aria_menu.html), it's done here to make sure the element can be clicked, otherwise iirc test fails.
Assignee | ||
Updated•13 years ago
|
Blocks: a11ytestdev
Reporter | ||
Comment 2•13 years ago
|
||
With the patch in bug 524545 applied, I get a timeout in the test states/test_comboboxes.xul The main window is scrolling. This has been an issue with other tests (such as bug 667034). One solution, if possible, is to cancel scroll and mousescroll events.
Assignee | ||
Comment 3•13 years ago
|
||
This test uses DOMNode.scrollIntoView(true) which seems to cause a problem. Anything to be fixed in a11y tests?
Comment 4•13 years ago
|
||
For some of the tests, we even need potential scrolling to happen, to test for correct same page anchor jumps, for example. We need a scrolling_start event to be fired so screen readers know that the browser just performed a jump to a same page anchor from a link.
Reporter | ||
Comment 5•13 years ago
|
||
Ah, ok, scrollIntoView scrolls all parent frames as well. I wonder if other tests have had this issue. The simplest fix may be to change the tests that use scrollIntoView to scroll back again.
Comment 6•13 years ago
|
||
(In reply to comment #5) > The simplest fix may be to change the tests that use scrollIntoView to > scroll back again. What's the simplest way to do that?
Reporter | ||
Comment 7•13 years ago
|
||
You should be able to use window.top.scrollTo(0, 0);
Assignee | ||
Comment 8•13 years ago
|
||
Enn, can you check if it helps please?
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Assignee | ||
Updated•13 years ago
|
Attachment #549121 -
Flags: review?(trev.saunders)
Comment 9•13 years ago
|
||
Comment on attachment 549121 [details] [diff] [review] patch YEAH, THAT SHOULD FIX THIS INVOKER CAUSING A SCROLL THAT DOESN'T GET UNDONE
Attachment #549121 -
Flags: review?(trev.saunders) → review+
Assignee | ||
Comment 10•13 years ago
|
||
landed http://hg.mozilla.org/mozilla-central/rev/3a78019c34e5
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•13 years ago
|
Target Milestone: --- → mozilla8
Reporter | ||
Comment 11•13 years ago
|
||
Yes, the tests are ok now.
You need to log in
before you can comment on or make changes to this bug.
Description
•