Closed Bug 506389 Opened 10 years ago Closed 10 years ago
Some same page links do not fire EVENT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199) 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:188.8.131.52) 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.
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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 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. ;)
Attachment #397599 - Flags: review?(marco.zehe) → review+
(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 :)
10 years ago
Attachment #397599 - Flags: review?(bolterbugz) → review+
landed on 1.9.3 - http://hg.mozilla.org/mozilla-central/rev/beecc75d1001
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
William, have you seen this in wild? Should we try to get an approval to land on previous versions of Firefox?
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.)
Thank you for use case. It should be good argument for approval request.
Attachment #397599 - Flags: approval1.9.2?
Comment on attachment 397599 [details] [diff] [review] patch trivial fix, mochitests are included, used in a wild.
Attachment #397599 - Flags: approval1.9.2? → approval1.9.2+
landed on 1.9.2 - http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e7513de577cc
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)
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!
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
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.
You need to log in before you can comment on or make changes to this bug.