568434 - about:neterror page loading isn't subject of state start/stop nsIWebProgressListener notifications

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[alexander :surkov (:asurkov)]

When I type URL like "t.t" I get
1. state start notification for existing document, request uri is "http://t.t"
2. state start notification for existing document, request uri is "http://www.t.t"
3. state top notification for existing document, request uri is "http://t.t"
4. state top notification for existing document, request uri is "http://www.t.t"
5. pagehide event for existing document
6. new document for "about:neterror" is created.

There is no state start/stop notifications for about:neterror page.

Primary accessibility relies on nsIWebProgressListener notification to fire accessibility events to AT. Since it there's no notifications for error pages then it was workarounded in bug 302227. I think this is kind of hack which complicates the code and not very nice and it doesn't work for error pages if they have subdocuments.

I'm not sure whether this is bug or feature but I'd like to get it fixed. Your thoughts please?

Comment 1

[alexander :surkov (:asurkov)]

(In reply to comment #0)
> Since it there's no notifications for error pages
> then it was workarounded in bug 302227.

Sorry, right bug number is bug 305813.

Comment 2

[alexander :surkov (:asurkov)]

(In reply to comment #0)

> There is no state start/stop notifications for about:neterror page.

progress listener is for nsIWebProgress::NOTIFY_STATE_DOCUMENT

Comment 3

[Boris Zbarsky [:bzbarsky]]

Right, these are background loads, for various reasons.  There are existing bugs about the fact that you don't get onload events for them, but there certainly shouldn't be web progress notifications, just like for other background loads...

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> Right, these are background loads, for various reasons.  There are existing
> bugs about the fact that you don't get onload events for them, but there
> certainly shouldn't be web progress notifications, just like for other
> background loads...

Ok, then it's a feature. What's a reason some pages are loaded with webprogress notifications, but some of them are loaded in background? Is the reason of about:neterror silent loading the webprogress notified listeners the page was failed to load and that should be enough? This looks reasonable for web developers but since webprogress notifies about chrome pages loading it confuses me.

Any way I don't mind if I have the way to be notified about document loads in background. "DOMContentLoaded" is not very good because it's fired for all loaded documents. I can't switch to "DOMContentLoaded" entirely because a11y needs to fire events for root document when its all children were loaded.

Ideally I would like to have interface for a11y to get notifications the page is going to be reloaded or new document is going to be loaded instead of it and when the document was loaded.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Right now there is no good way to detect error pages loading, period.

That said, they should just fire onload (we have existing bugs on that).  And onload will do what you want, no?

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)
> Right now there is no good way to detect error pages loading, period.

Is it time expensive to fix this?

> That said, they should just fire onload (we have existing bugs on that).  And
> onload will do what you want, no?

No, we don't listen onload in a11y. Currently we listen webprogress notifications and DOMContentLoaded (DOMContentLoaded is a hack to support error pages).

Is there documents loaded in background other than error pages?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Is it time expensive to fix this?

Hard to say. It involves changing some pretty fragile code.

> No, we don't listen onload in a11y.

Why not?  Not that it matters, since error pages don't fire it...

> Is there documents loaded in background other than error pages?

That actually get rendered?  Usually not.  Of course an extension could do it if it wanted.

Comment 8

[alexander :surkov (:asurkov)]

Closing as wontfix (or should be invalid?) since this is how background loads working. I don't have any objections to ask for a changes.