628673 - Opening a page with a specific anchor target does not place NVDA virtual cursor on the target

Status: RESOLVED DUPLICATE of bug 691734

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

In Firefox 3.6, when opening
https://wiki.mozilla.org/Accessibility/HTML5_Forms#placeholder_attribute
the NVDA virtual buffer would be placed on the heading "Placeholder attribute", which is where the anchor target is on this particular page.
In Firefox 4.0b10pre, this is no longer the case. Esp after bug 498015, this no longer works at all, despire bug 625693 and related bug fixes from bug 606924. It intermittently works in builds older than bug 498015, but not reliably, either.

This is true for all kinds of pages for which there is an anchor jump defined in the URL.

STR:
1. Open NVDA and Firefox.
2. Paste https://wiki.mozilla.org/Accessibility/HTML5_Forms#placeholder_attribute into your address bar and press Enter.

Expected: Page loads, and NVDA's virtual cursor is placed on the heading.
Actual: NVDA's virtual cursor is at the top of the page.

3. Now, press TAB. This will bring focus to the first link after the "Placeholder attribute" heading. But from where the NVDA virtual cursor is, the expectation would be to start tabbing from the top of the page.

So, Firefox knows the focus should be on the heading, it just doesn't tell NVDA.

Comment 1

[alexander :surkov (:asurkov)]

Jamie, if you receive scroll end event right after document loaded event then is it possible you can miss it because vb is not created yet?

Comment 2

[James Teh [:Jamie]]

(In reply to comment #1)
> Jamie, if you receive scroll end event
We've always used scrollingStart, not scrollingEnd.

> right after document loaded event then
> is it possible you can miss it because vb is not created yet?
Only if the document doesn't have focus at the time; e.g. the user alt+tabbed, ctrl+tabbed, tabbed, etc. away while it was loading. This is why I filed bug 617544. However, this is true for Firefox 3.6 as well; there should be no change in FF4.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> (In reply to comment #1)
> > Jamie, if you receive scroll end event
> We've always used scrollingStart, not scrollingEnd.
> 
> > right after document loaded event then
> > is it possible you can miss it because vb is not created yet?
> Only if the document doesn't have focus at the time; 

focus means focused state or focus event?

Comment 4

[James Teh [:Jamie]]

(In reply to comment #3)
> > > Jamie, if you receive scroll end event
> > > right after document loaded event then
> > > is it possible you can miss it because vb is not created yet?
> > Only if the document doesn't have focus at the time; 
> focus means focused state or focus event?
Focus event. However, ti could have been focused a while ago; i.e. we don't need the focus event right before documentLoadComplete.

Basically, in order to detect a Gecko document when it gets focus, NVDA checks that the window class name starts with "Mozilla" (we still need to use the window class name prefix, as there are too many different types of documents), that the role is document and that it has the readOnly state. Once this is determined, the document will be rendered into a buffer immediately if it does not have the busy state. If it does have the busy state, NVDA will wait for a documentLoadComplete event before it does the busy state check again. If it loses focus before this happens (usually due to user action), we go back to the start.

Comment 5

[alexander :surkov (:asurkov)]

The scrollingStart event is fired before document loaded event (i.e. fired when document has busy state). That makes NVDA to ignore it, right?

Comment 6

[James Teh [:Jamie]]

(In reply to comment #5)
> The scrollingStart event is fired before document loaded event (i.e. fired when
> document has busy state). That makes NVDA to ignore it, right?
Correct.

Comment 7

[alexander :surkov (:asurkov)]

Jamie, I patched Gecko so I get

1. focus on document (busy, focused)
2. document load complete (focused, no busy)
3. scrolling start (on heading, the document has focused state, no busy)

NVDA starts to read the page from beginning anyway. Do you create vb synchronously when you handle document load event or store events until vb is created after you scheduled its creation? Do you have ideas why this order of events doesn't help?

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 9

[James Teh [:Jamie]]

(In reply to comment #7)
> NVDA starts to read the page from beginning anyway. Do you create vb
> synchronously when you handle document load event or store events until vb is
> created after you scheduled its creation?
Ack. I forgot we create it asynchronously after receiving the event and don't store events for the buffer. The theory is that generally, we don't need any events for the buffer until the buffer is actually created. This is very much a timing issue. This is another reason for needing bug 617544: there shouldn't be any event state that can't be determined by making a query. I guess it must just be working for Marco in 3.6 because the timing is different.

We might be able to hack around this in NVDA, but honestly, I think it might just be worth waiting until bug 617544 can be done, which I imagine will be after FF4. The reason is that even if this is fixed, it'll still break if you move focus out of the document while it is loading. Also, this rarely works for me even in Firefox 3.6, probably because of the above timing issue.

It's probably still more correct to fire this event after the document loses the busy state.

Comment 10

[alexander :surkov (:asurkov)]

(In reply to comment #9)
> (In reply to comment #7)
> > NVDA starts to read the page from beginning anyway. Do you create vb
> > synchronously when you handle document load event or store events until vb is
> > created after you scheduled its creation?
> Ack. I forgot we create it asynchronously after receiving the event and don't
> store events for the buffer. The theory is that generally, we don't need any
> events for the buffer until the buffer is actually created. This is very much a
> timing issue. This is another reason for needing bug 617544: there shouldn't be
> any event state that can't be determined by making a query.


> We might be able to hack around this in NVDA, but honestly, I think it might
> just be worth waiting until bug 617544 can be done, which I imagine will be
> after FF4. The reason is that even if this is fixed, it'll still break if you
> move focus out of the document while it is loading. Also, this rarely works for
> me even in Firefox 3.6, probably because of the above timing issue

I agree bug 617544 is good fix but not fx4 timeframe while this bug it is.

That can be a fix on our side. Or alternately you could fix NVDA for this. Though it sounds like you said it can be hard. Another point would be that NVDA fix is reasonable if NVDA is shipped not much later than Fx4 but it doesn't look likely though. Perhaps neither of us could do anything but I realize how is annoying this bug might be.

> It's probably still more correct to fire this event after the document loses
> the busy state.

I do this in the patch that attached to the bug. But this after is too short I think (scollingstart and documentload must be fired in timeout but it looks like that's not enough)

Comment 11

[alexander :surkov (:asurkov)]

Attachment: try

I tried different ways but wasn't able to make behavior stable. Perhaps we should go by bug 617544 to fix this one.

Comment 12

[alexander :surkov (:asurkov)]

Marco, can we ship Firefox without this bug fixed?

Comment 13

[Marco Zehe (:MarcoZ)]

Yes, we can. With all the fixes to a11y tree creation, this is now not behaving worse than 3.6 is. We should eventually put in a correct fix, but this can happen in the FX5 timeframe.

Comment 14

[alexander :surkov (:asurkov)]

> Yes, we can. We should eventually put in a correct fix, but this can
> happen in the FX5 timeframe.

Ok, cancel blocking status. We should do this in Fx5 timeframe, since I bet this bug must be annoying.(In reply to comment #13)

> With all the fixes to a11y tree creation, this is now not behaving
> worse than 3.6 is.

I thought fx3.6 handles that correctly sometimes but fx4 handles never.

Comment 15

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

Excellent. Maybe create a meta bug for FX5 a11y?

Comment 16

[alexander :surkov (:asurkov)]

(In reply to comment #15)
> Excellent. Maybe create a meta bug for FX5 a11y?

there's one: bug 632301

Comment 17

[alexander :surkov (:asurkov)]

After bug 691734 is fixed, we have to fix bug 617544 and nothing to fix here actually. I think it's ok to mark this bug as dupe of bug 691734.