STR: 1. Launch Firefox from the Windows start menu. For example, set it as your default browser and launch the "Internet" shortcut from the top level start menu location. Expected: An OBJ_STATE_CHANGE event with STATE_BUSY should be fired when the document starts loading, another that clears the STATE_BUSY when the document load finishes. This happens when launching Firefox from the desktop or when opening an URL from an e-mail, but not when launching it from the start menu.

The block that starts the firing of STATE_BUSY starts here: http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsDocAccessible.cpp#903 What I'm noticing is that we fire two events: One inside the "if (!isFinished)" block, called fireAccessibleEvent, and one outside, which gets fired in any case: nsAccUtils::FireAccEvent. What's the difference between these two? And should they be both be firing in this case?

(In reply to comment #1) > What I'm noticing is that we fire two events: One inside the "if (!isFinished)" > block, called fireAccessibleEvent, and one outside, which gets fired in any > case: nsAccUtils::FireAccEvent. What's the difference between these two? Whenever a FireDocLoadEvents call is made on the main document for a non load/stop event it looks like the decision was made to fire a busy state change event, before the event type that was passed in (e.g. a load start event). Based on the comments it sounds like some ATs listen for, and expect this event, perhaps to guard against accessing their main document cache. It could be that they only use this event, and don't listen to other more specific events, but we need to fire the specific ones as well, of course. > And should they be both be firing in this case? Yeah I think so. This bug sounds like it might be hitting one of the earlier bail outs (after the mIsLoadCompleteFired guard).

Marco, is it still valid?

No, it is no longer valid in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0. Closing as WFM.