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.

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

Marco, could you check it helps?

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.

Nit: this comment is in the wrong place // Not a frame or iframe Otherwise, after careful review, it looks correct to me.

Comment on attachment 318968 [details] [diff] [review] patch a=beltzner; if this doesn't get it, we should back out the other patch.

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

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.

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.

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.

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