748082 - Set STATE_BUSY on document's parent accessible when loading

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Eitan Isaacson [:eeejay]]

Currently, besides listening for STATE_BUSY state change events, there is no way to know a document is being loaded. The busy state has two shortfalls:
1. If it is a new document (ie. load a doc in new tab). No state change event is emitted, and the object is simply created with STATE_BUSY, so you need to look out for those documents.
2. Clicking a link to download a file will also invoke a STATE_BUSY even though the current document is not being unloaded.

It would be nice is EVENT_DOCUMENT_LOAD_COMPLETE and EVENT_DOCUMENT_LOAD_STOP would bookend EVENT_DOCUMENT_LOADING.

Comment 1

[alexander :surkov (:asurkov)]

technically EVENT_DOCUMENT_LOADING is a dupe of reorder event on document container, it's fired when new document is attached to the tree.

Comment 2

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #1)
> technically EVENT_DOCUMENT_LOADING is a dupe of reorder event on document
> container, it's fired when new document is attached to the tree.

Not really, the reorder event only happens when a new document is attached. I want a pair of events that are sent when the spinner starts and stops.

The document that fires the first STATE_BUSY event is different from the one that ulimately fires EVENT_DOCUMENT_LOAD_COMPLETE.

Maybe there needs to be a pair of events on the document's parent object that doesn't go anywhere. This would be equivalent to the visual spinner that starts and stops.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #2)
> (In reply to alexander :surkov from comment #1)
> > technically EVENT_DOCUMENT_LOADING is a dupe of reorder event on document
> > container, it's fired when new document is attached to the tree.
> 
> Not really, the reorder event only happens when a new document is attached.
> I want a pair of events that are sent when the spinner starts and stops.

I see what you want to achieve from UI perspective but not sure what we can do on API level. Note event_document_loaded is not related with spinner state (and I think it shouldn't), so making event_document_loading related with spinner is not correct.

> Maybe there needs to be a pair of events on the document's parent object
> that doesn't go anywhere. This would be equivalent to the visual spinner
> that starts and stops.

perhaps you need to watch events from spinner instead.

Comment 4

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #3)
> perhaps you need to watch events from spinner instead.

Not all apps have accessible spinners. Android does not have a XUL tab or a spinner.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #4)
> (In reply to alexander :surkov from comment #3)
> > perhaps you need to watch events from spinner instead.
> 
> Not all apps have accessible spinners. Android does not have a XUL tab or a
> spinner.

then I'm not sure what you want when you say it should be equivalent to spinner behavior. Can you describe when and what target for EVENT_DOCUMENT_LOADING should be fired?

Comment 6

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #5)
> (In reply to Eitan Isaacson [:eeejay] from comment #4)
> > (In reply to alexander :surkov from comment #3)
> > > perhaps you need to watch events from spinner instead.
> > 
> > Not all apps have accessible spinners. Android does not have a XUL tab or a
> > spinner.
> 

i don't know if i was clear here. there is a spinner in android, just not a XUL spinner. it is implemented in the native Java ui.

> then I'm not sure what you want when you say it should be equivalent to
> spinner behavior. Can you describe when and what target for
> EVENT_DOCUMENT_LOADING should be fired?

the second a user clicks on a link they will see a spinner/throbber/status bar activity, etc. every browser has a way for the user to see that it is busy doing something.

i just want to have simple events to know when the tab is busy being loaded and when it is done. something equivelent to the visual feedback.

what i learned while working on bug 745986 is that getting activity feedback from the document (be it BUSY state, or LOAD_COMPLETE event, etc), is that it is the wrong way to to it. since you need to listen to a whole collection of events and store objects across events and do weird forensics to know what each event means.

logically, the activity in the ui is being displayed at the tab level, not on the document level. so i think these events should be associated with the tab.

Comment 7

[alexander :surkov (:asurkov)]

so you want to have an event targeted to the tab (not clear which one) when browser is busy doing something (spinner spins). Maybe the best way to introduce some DOM event for this since it appears existing ATs don't really need to track a browser's spinner. At least that'd be a good way to prototype the feature.

Comment 8

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #7)
> so you want to have an event targeted to the tab (not clear which one) when
> browser is busy doing something (spinner spins). Maybe the best way to
> introduce some DOM event for this since it appears existing ATs don't really
> need to track a browser's spinner. At least that'd be a good way to
> prototype the feature.

I think a good solution would be having a STATE_BUSY set on the document's parent accessible. Actually, if you don't mind, I am going to change the bug's title..

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #8)

> I think a good solution would be having a STATE_BUSY set on the document's
> parent accessible. 

this could give us unwanted side effect when AT don't announce the changes from parent document when child document is loading. Say when you work with your mail box and some ad placed as iframe is changed.

> Actually, if you don't mind, I am going to change the
> bug's title..

it's ok, the bug can be morphed if it's kept clean (sometimes it makes sense to file new bug if the bug is chatty and the approach was changed).

Comment 10

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #9)
> (In reply to Eitan Isaacson [:eeejay] from comment #8)
> 
> > I think a good solution would be having a STATE_BUSY set on the document's
> > parent accessible. 
> 
> this could give us unwanted side effect when AT don't announce the changes
> from parent document when child document is loading. Say when you work with
> your mail box and some ad placed as iframe is changed.
> 

Forgot to reply to this earlier.. the state would be set on the internal frame, not on the parent document. I think that answers your concern.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #10)

> Forgot to reply to this earlier.. the state would be set on the internal
> frame, not on the parent document. I think that answers your concern.

I see. state busy on iframe accessible when old document goes away and until new document is completely loaded?

Comment 12

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #11)
> (In reply to Eitan Isaacson [:eeejay] from comment #10)
> 
> > Forgot to reply to this earlier.. the state would be set on the internal
> > frame, not on the parent document. I think that answers your concern.
> 
> I see. state busy on iframe accessible when old document goes away and until
> new document is completely loaded?

Exactly!

Or until out-of-band download begins. For example, you click on a link to a zip, the spinner goes and then it stops when the save dialog appears. So the busy state should end when the spinner ends.

Comment 13

[alexander :surkov (:asurkov)]

this shouldn't harm us, cc'ing Jamie

Comment 14

[James Teh [:Jamie]]

I can't see any problem with this as long as it only affects the parent iframe; i.e. doesn't change the current busy state behaviour for documents, etc.