431642 - Put back state change event when doc starts loading (e. g. when pressing ENTER on a link)

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

Regression from bug 417249. In the big patch that finally got in, attachment 305632 [details] [diff] [review], we eliminate the state change to busy, starting on line 496 of that patch.

The intention was to make it more robust to spurious loads, but not to eliminate it.

This would also explain the intermittant doc update failures I've seen with JAWS over the past couple of weeks, but due to no reliable steps to reproduce, hadn't filed a bug yet.

Bill Smith of GWMicro sent me e-mail regarding this issue. He said:

> Window-Eyes expects to get an STATECHANGE on the role DOCUMENT with a state BUSY set when a page starts loading.   Then when the page is done loading, we
> get a STATECHANGE  on the document with BUSY not set.
> 
> Right now we just get the second statechange when the page is done loading.  
> 
> The effect on the current version of Window-Eyes is that we don't automatically reload a page when you tgo to a new page.

Comment 1

[William Smith]

This also affects browsing ftp sites such as ftp://ftp.mozilla.org

Comment 2

[alexander :surkov (:asurkov)]

Attachment: patch

Marco, could you check it helps?

Comment 3

[Marco Zehe (:MarcoZ)]

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

r=me, it works, and it also does not reintroduce bug 405951 in Thunderbird. However since this is rather sensitive code, I'd prefer if Aaron look this over as well.

Comment 4

[Aaron Leventhal]

Nit: this comment is in the wrong place
   // Not a frame or iframe

Otherwise, after careful review, it looks correct to me.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

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

a=beltzner; if this doesn't get it, we should back out the other patch.

Comment 6

[Marco Zehe (:MarcoZ)]

Checking in accessible/src/base/nsDocAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsDocAccessible.cpp,v  <--  nsDocAccessible.cpp
new revision: 1.242; previous revision: 1.241
done

Comment 7

[William Smith]

I've checked out the 05/04 nightly and it's working in every case except when "Gecko/2008050406-Minefield" initially loads.   I don't see a BUSY state change on the initial load.

Comment 8

[William Smith]

The effects are more complicated than what I just wrote.   Window-Eyes doesn't load the page on http://www.evilmadscientist.com when it is a home page and you launch the 05/04 nightly build, while http://www.comics.com will appear to load the page, but Window-Eyes will skip some frames.

There are changes in how Firefox 2 and Firefox 3 use reorder events.

We were using REORDER events fired on all of the frames with BSTR role "iframe".   It looks like we also accept BSTR role "frame", but I didn't see Firefox 2 firing any with the latter role.  These events start a timer to reload the page.

I didn't see Firefox 3 firing any reorder events with either of these roles as pages loaded.

Comment 9

[William Smith]

I was concerned yesterday because I couldn't duplicate evilmadscientist.com.   Today I found that if the side bar was missing I could break evilmadscientis.com consistently.

Comment 10

[Marco Zehe (:MarcoZ)]

Surkov, Aaron, any commeents on the Reorder events? Were these removed on purpose?