Last Comment Bug 672912 - Some accessibility tests scroll window
: Some accessibility tests scroll window
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla8
Assigned To: alexander :surkov
:
Mentors:
Depends on:
Blocks: a11ytestdev 524545
  Show dependency treegraph
 
Reported: 2011-07-20 12:44 PDT by Neil Deakin
Modified: 2011-07-29 07:53 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (726 bytes, patch)
2011-07-28 08:26 PDT, alexander :surkov
tbsaunde+mozbugs: review+
Details | Diff | Splinter Review

Description Neil Deakin 2011-07-20 12:44:42 PDT
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.
Comment 1 alexander :surkov 2011-07-20 22:26:48 PDT
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.
Comment 2 Neil Deakin 2011-07-21 01:00:56 PDT
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.
Comment 3 alexander :surkov 2011-07-21 01:10:39 PDT
This test uses DOMNode.scrollIntoView(true) which seems to cause a problem. Anything to be fixed in a11y tests?
Comment 4 Marco Zehe (:MarcoZ) on PTO until August 15 2011-07-21 05:22:04 PDT
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.
Comment 5 Neil Deakin 2011-07-21 14:05:18 PDT
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 David Bolter [:davidb] 2011-07-25 06:11:19 PDT
(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?
Comment 7 Neil Deakin 2011-07-27 14:48:22 PDT
You should be able to use window.top.scrollTo(0, 0);
Comment 8 alexander :surkov 2011-07-28 08:26:02 PDT
Created attachment 549121 [details] [diff] [review]
patch

Enn, can you check if it helps please?
Comment 9 Trevor Saunders (:tbsaunde) 2011-07-28 12:45:04 PDT
Comment on attachment 549121 [details] [diff] [review]
patch

YEAH, THAT SHOULD FIX THIS INVOKER CAUSING A SCROLL  THAT DOESN'T GET UNDONE
Comment 10 alexander :surkov 2011-07-28 19:39:50 PDT
landed http://hg.mozilla.org/mozilla-central/rev/3a78019c34e5
Comment 11 Neil Deakin 2011-07-29 07:53:44 PDT
Yes, the tests are ok now.

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