Closed Bug 551385 Opened 15 years ago Closed 15 years ago

document load start event is never fired

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: surkov, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

The reason is when we get STATE_START state flag in OnStateChange the document is not ready. We always get some HTML document from nsIWebProgress object (even if chrome XUL document is loaded) which is not accessible. I suspect this is kind of stub. I suggest to pend document creation and document load start event and listen to STATE_TRANSFERRING state. When we are notified of this state then the document is created, so we are safe to create document accessible. The problem of state tranfsering is it's not always fired for XUL documents. Here we get STATE_START state and then STATE_STOP state with failure status. I think we can figure out what's wrong later.
The wrong document problem on STATE_START was discussed in bug 417249 and we have open bug 419626 for this. However we don't fire start/end load document events in nsDocAccessible::FireDocLoadEvent for frame/iframe documents starting from checkin http://hg.mozilla.org/mozilla-central/rev/c516d78f90fd (which was supposed to fix bug 417249, bug 417578, bug 405951, bug 413778, bug 412878). I still don't get a reason.
The reason is "Fire show/hide events to indicate frame/iframe content is new, rather than doc load event which causes screen readers to act is if entire page is reloaded".
Depends on: 566103
fixed by 566103. We don't want document start event any more since we stopped to use it internally and there's no analogy in AT.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.