nsAccessibilityService::NotifyOfAnchorJumpTo() obtains an accessible to fire scrolling_end event, it triggers before we created initial document tree (bug 606924) so it makes us to create accessible tree early what's unwanted.

Is this also why I'm seeing so many failures with NVDA when loading a page that has a direct anchor jump in the URL?

(In reply to comment #1) > Is this also why I'm seeing so many failures with NVDA when loading a page that > has a direct anchor jump in the URL? It could be if nsAccessibilityService::NotifyOfAnchorJumpTo() is called when layout is not finished (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#4022). I don't know whether this is true. We could wait for a try build or ask roc or bz.

(In reply to comment #0) > nsAccessibilityService::NotifyOfAnchorJumpTo() obtains an accessible to fire > scrolling_end event for the record: correctness: scrolling_end -> scrolling_start

(In reply to comment #1) > Is this also why I'm seeing so many failures with NVDA when loading a page that > has a direct anchor jump in the URL? Marco, btw, what kind of failures?

(In reply to comment #4) > (In reply to comment #1) > > Is this also why I'm seeing so many failures with NVDA when loading a page that > > has a direct anchor jump in the URL? > > Marco, btw, what kind of failures? In FX 3.6.x, NVDA almost always jumps to the correct anchor target with the virtual cursor. In FX 4, current nightly builds and the try-server from bug 498015, I have to press tab once, forcing a focus jump to some focusable item following the actual anchor target. So it appears NVDA doesn't receive the event saying that the virtual cursor should go to the anchor target, it always shows me the first line of the virtual buffer.

OK, I see on bug 437607 layout calls into us... yes I think this bug makes sense will review shortly.

Comment on attachment 503795 [details] [diff] [review] patch r=me, looks right.

Before requesting approval, let's get try build results to see how important this fix is.

(In reply to comment #9) > Before requesting approval, It's needed for bug 606924 what should make it blocking. > let's get try build results to see how important > this fix is. i'll run try server build before pushing.

(In reply to comment #10) > (In reply to comment #9) > > Before requesting approval, > > It's needed for bug 606924 what should make it blocking. > Ah OK. > > let's get try build results to see how important > > this fix is. > > i'll run try server build before pushing. Great, also maybe check with Jamie to see if this mitigates bug 617544?

(In reply to comment #11) > Great, also maybe check with Jamie to see if this mitigates bug 617544? that's different

(In reply to comment #12) > (In reply to comment #11) > > > Great, also maybe check with Jamie to see if this mitigates bug 617544? > > that's different Possibly, but it depends why it was filed.

(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > > > Great, also maybe check with Jamie to see if this mitigates bug 617544? > > > > that's different > > Possibly, but it depends why it was filed. iirc they miss an event because they didn't listen it, not because we didn't fire it, that makes me think that one is unrelated.

(In reply to comment #14) > > > > Great, also maybe check with Jamie to see if this mitigates bug 617544? > iirc they miss an event because they didn't listen it, not because we didn't > fire it, that makes me think that one is unrelated. I was never sure whether Gecko did fire it, but I never actually checked. For me, even in Firefox 3.6.x, NVDA doesn't always seem to move the cursor to an anchor when first loading a page. However, this could be because we create the buffer after the event was fired. In any case, bug 617544 is still very much valid but separate.

try server build - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-4d91a73094d6

I don't notice any difference, NVDA still doesn't jump to any anchors on page load if they are specified.

landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/bb98075d9d2c

Are we assuming that comment 17 is because of a separate bug?

(In reply to comment #19) > Are we assuming that comment 17 is because of a separate bug? right, sounds like unfiled one.

(In reply to comment #20) > (In reply to comment #19) > > Are we assuming that comment 17 is because of a separate bug? > > right, sounds like unfiled one. Bug 628673 is now filed for this.