506389 - Some same page links do not fire EVENT_SYSTEM_SCROLLINGSTART

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[William Smith]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)

When a web page links to an anchor on the same page, visually the link works, but when the target anchor is not on an "<A>" element, the MSAA event EVENT_SYSTEM_SCROLLINGSTART is not fired.

The attached page fires a scrolling start event when you traverse "Link to Anchor", but does not do so when you traverse "Link to div"

This is different from https://bugzilla.mozilla.org/show_bug.cgi?id=437607 because the same page links always scroll correctly, it is just the missing msaa event that is wrong.  Also, the behavior is the same when you traverse the same link twice.

Reproducible: Always

Steps to Reproduce:
1. Open the attached page with accevent monitoring event_system_scrollingstart
2. click on "Link to div"
Actual Results:  
several msaa events get fired, but SYS_SCROLLINGSTART is not one of them.   When you traverse the other link, the scrolling start is fired

Expected Results:  
event_system_scrolling start is fired for both link traversals.

event_system_scrollingstart indicates that a same page anchor has been visited so that Window-Eyes knows to relocate focus to the destination.

Comment 1

[William Smith]

Attachment: a web page that has two same page links - one to an "<A>" node and one to a <div>

Comment 2

[Marco Zehe (:MarcoZ)]

Confirmed. Surkov, can you take a look at this since it affects all screen readers? Possibly in tandem with bug 437607, which falls into the same area of the EVENT_SCROLLING_START?

Comment 3

[alexander :surkov (:asurkov)]

regression from bug 366438

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> Confirmed. Surkov, can you take a look at this since it affects all screen
> readers? Possibly in tandem with bug 437607, which falls into the same area of
> the EVENT_SCROLLING_START?

bug 437607 isn't related with this one. I'll take care about it after this one.

Comment 5

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 6

[Marco Zehe (:MarcoZ)]

Comment on attachment 397599 [details] [diff] [review]
patch

r=me with 1 nit:
>+        return "scrolling start handling handling for " + prettyName(aAcc);

The word "handling" is doubled here.

I still find it strange that you can actually have an href point to an ID instead of a real anchor, but since it works I won't complain. ;)

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)

> The word "handling" is doubled here.

fixed locally

> I still find it strange that you can actually have an href point to an ID
> instead of a real anchor, but since it works I won't complain. ;)

that's based on William's testcase. I invented nothing :)

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 397599 [details] [diff] [review]
patch

r=me; nice catch.

Comment 9

[alexander :surkov (:asurkov)]

landed on 1.9.3 - http://hg.mozilla.org/mozilla-central/rev/beecc75d1001

Comment 10

[alexander :surkov (:asurkov)]

William, have you seen this in wild? Should we try to get an approval to land on previous versions of Firefox?

Comment 11

[William Smith]

Yes, there is a Daisy reader plugin by Benetech for Firefox that puts anchors destinations on ID items all over the place.  (You might want to contact them for more details or a sample document.)

Comment 12

[alexander :surkov (:asurkov)]

Thank you for use case. It should be good argument for approval request.

Comment 13

[alexander :surkov (:asurkov)]

Comment on attachment 397599 [details] [diff] [review]
patch

trivial fix, mochitests are included, used in a wild.

Comment 14

[alexander :surkov (:asurkov)]

landed on 1.9.2 - http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e7513de577cc

Comment 15

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre (.NET CLR 3.5.30729)

Comment 17

[Marco Zehe (:MarcoZ)]

Ricardo, can you test your testcase with Firefox 3.6beta2 and report back here if it fixes your use case? We think it should. Thanks!

Comment 18

[Ricardo]

just tested with firefox 3.6b2, here are results;

Focus *does* move to the designated area: if i put anchor or just reference the ID (e.g. <td id="nav-here" />) the focus does scroll the page down to the designated area; (btw, using ID is XHTML compliant, as opposed to using another anchor <a name="nav-here" />;(obsolete, but should still work, and it does in this beta version)

However, that said, this issue again is for Section 508 compliant (screen readers), and it does not work. In reading the thread above, seems that there is another EVENT that is not being picked up?!?!? 

I am using window-eyes. The screen reader (SR) starts at the top of the page as expected. Once the local href link is clicked, the focus does move down to the location on the page, the page does scroll (if needed) however the SR starts reading from the top again. I tried different anchor vs. ID but same results. In all cases the focus/scroll does work, but SR does not follow (reading text) where the focus is, it always defaults back to top of page. Hope this helps

you may want to contact the folks at window-eyes, here is their link: http://www.gwmicro.com/ - 

Again, this does work on IE.
-ricardo

Comment 19

[Marco Zehe (:MarcoZ)]

Ricardo, you are talking about bug 437607 which was also recently fixed on trunk, which is already a version higher than 3.6. So to see if that fully fixes your problem, you might want to download an 3.7a1pre nightly and try it with that, too.

BTW this bug we are currently in was specifically filed because of a report from the GW Micro developers, and they provided the original testcase for this bug. So we are in contact with them already, and they know the status of this bug.