provisional load failure with net::ERR_ABORTED

[oshima]

(from right address this time)

Hello,

Can someone tell me the difference between provisional load error and plain "load error", and

in which condition RenderView::didFailProvisionalLoad is called with net::ERR_ABORTED?

I'm getting this when loading a page right after network connection is (supposed to be) resumed,

and want to know exactly why and how.

Thanks!

- oshima

[Darin Fisher]

First off, a provisional load happens when a Frame (DOM Window) is asked to navigate, but the

HTTP response has not yet been received.  We haven't yet disturbed the existing Document in

the Frame.

Once the HTTP response headers are available, we can inspect the MIME type, and decide how

to render it.  If we determine that the response can be rendered by WebKit or a plugin, then we

set about replacing the Document with a new one in which we will render the HTTP response.

This causes the corresponding provisional load to transition to a normal load.  (See RenderView::

didCommitProvisionalLoad.)

Now, answering your question... if the HTTP response is interrupted while the corresponding load

is still provisional, then RenderView::didFailProvisionalLoad will be called.  Otherwise, if the load

had already been committed, but failed to be downloaded fully, then RenderView::didFailLoad

will be called.

The error code net::ERR_ABORTED is intended to only be generated when a user action causes

a load to be interrupted.  This can happen when a new navigation interrupts an existing one, or

when the user clicks the STOP button.

-Darin

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[oshima]

Thanks Darin, this is very helpful. 

On Fri, Apr 15, 2011 at 9:07 AM, Darin Fisher <da...@chromium.org> wrote:

First off, a provisional load happens when a Frame (DOM Window) is asked to navigate, but the

HTTP response has not yet been received.  We haven't yet disturbed the existing Document in

the Frame.

Once the HTTP response headers are available, we can inspect the MIME type, and decide how

to render it.  If we determine that the response can be rendered by WebKit or a plugin, then we

set about replacing the Document with a new one in which we will render the HTTP response.

This causes the corresponding provisional load to transition to a normal load.  (See RenderView::

didCommitProvisionalLoad.)

Now, answering your question... if the HTTP response is interrupted while the corresponding load

is still provisional, then RenderView::didFailProvisionalLoad will be called.  Otherwise, if the load

had already been committed, but failed to be downloaded fully, then RenderView::didFailLoad

will be called.

The error code net::ERR_ABORTED is intended to only be generated when a user action causes

a load to be interrupted.  This can happen when a new navigation interrupts an existing one, or

when the user clicks the STOP button.

From your description, chrome seems to be believing that an existing navigation is interrupted by a new navigation

(as this happen w/o STOP button) when InterstitialPage::Procced is called under certain condition.

Can you point me the code that handles this new navigation scenario?

Thanks,

- oshima

[Darin Fisher]

On Fri, Apr 15, 2011 at 11:18 AM, oshima <osh...@chromium.org> wrote:

Thanks Darin, this is very helpful. 

On Fri, Apr 15, 2011 at 9:07 AM, Darin Fisher <da...@chromium.org> wrote:

First off, a provisional load happens when a Frame (DOM Window) is asked to navigate, but the

HTTP response has not yet been received.  We haven't yet disturbed the existing Document in

the Frame.

Once the HTTP response headers are available, we can inspect the MIME type, and decide how

to render it.  If we determine that the response can be rendered by WebKit or a plugin, then we

set about replacing the Document with a new one in which we will render the HTTP response.

This causes the corresponding provisional load to transition to a normal load.  (See RenderView::

didCommitProvisionalLoad.)

Now, answering your question... if the HTTP response is interrupted while the corresponding load

is still provisional, then RenderView::didFailProvisionalLoad will be called.  Otherwise, if the load

had already been committed, but failed to be downloaded fully, then RenderView::didFailLoad

will be called.

The error code net::ERR_ABORTED is intended to only be generated when a user action causes

a load to be interrupted.  This can happen when a new navigation interrupts an existing one, or

when the user clicks the STOP button.

From your description, chrome seems to be believing that an existing navigation is interrupted by a new navigation

(as this happen w/o STOP button) when InterstitialPage::Procced is called under certain condition.

Can you point me the code that handles this new navigation scenario?

I'm sorry, but I don't really understand what you are looking for.

-Darni

[oshima]

On Fri, Apr 15, 2011 at 11:32 AM, Darin Fisher <da...@chromium.org> wrote:

On Fri, Apr 15, 2011 at 11:18 AM, oshima <osh...@chromium.org> wrote:

Thanks Darin, this is very helpful. 

On Fri, Apr 15, 2011 at 9:07 AM, Darin Fisher <da...@chromium.org> wrote:

First off, a provisional load happens when a Frame (DOM Window) is asked to navigate, but the

HTTP response has not yet been received.  We haven't yet disturbed the existing Document in

the Frame.

Once the HTTP response headers are available, we can inspect the MIME type, and decide how

to render it.  If we determine that the response can be rendered by WebKit or a plugin, then we

set about replacing the Document with a new one in which we will render the HTTP response.

This causes the corresponding provisional load to transition to a normal load.  (See RenderView::

didCommitProvisionalLoad.)

Now, answering your question... if the HTTP response is interrupted while the corresponding load

is still provisional, then RenderView::didFailProvisionalLoad will be called.  Otherwise, if the load

had already been committed, but failed to be downloaded fully, then RenderView::didFailLoad

will be called.

The error code net::ERR_ABORTED is intended to only be generated when a user action causes

a load to be interrupted.  This can happen when a new navigation interrupts an existing one, or

when the user clicks the STOP button.

From your description, chrome seems to be believing that an existing navigation is interrupted by a new navigation

(as this happen w/o STOP button) when InterstitialPage::Procced is called under certain condition.

Can you point me the code that handles this new navigation scenario?

I'm sorry, but I don't really understand what you are looking for.

Sorry, I should have given more context. Here is the background.

ChromeOS has a "offline" page that is shown when you navigate while the system is offline.

This is implemented as an interstitial page, and it "proceed"s with loading when it becomes

online. I'm getting this provisional load error often (not not always) during this transition, and

I'm trying to identify why and how.

 From your description, the provisional load is failing not because HTTP connection was

interrupted/disconnected, but chrome seems to be believing that the navigation is interrupted

by a user request (which is not), and aborting the load before it receives HTTP response.

I'd like to know why chrome believes that the current navigation is interrupted and am

looking for the code that handles this case.

Thanks,

- oshima

[Darin Fisher]

Hmm, seems like you could have implemented that by extending the existing error page

infrastructure.  Why was that not done?

We should implement the HTML5 online/offline events and use that as a signal to the

standard error page to issue a reload.  (Note: the standard error pages already have a

reload button.)

[oshima]

More background.

This feature was evolved from the bug "restored tab fails to load pages when

a user logged in". That is, when you login in offline and becomes online, you get

a lot of "load failed" pages, so we wanted to wait start loading until the network stack

is ready to handle the request. I then have to deal with the case that it stays offline,

and using interstitial page is what I was recommend when I tried to solve this.

 I actually chatted with erikkay about using error page a bit later and we agreed that that's

the right direction, but I never had time to work on this change so far. (I made one change to handle installed apps)

Chrome currently wait 500ms before "proceeding". For m12, I was looking for an easy fix

that allow me to remove this 500ms hack, but If you think we should spend time on replacing it

instead, I'm happy to punt it to m13.

One difference in chromeos is that we shows 'sign up for broadband' message in the offline page

using extension. I assume the error page is just an html page, so this shouldn't be an issue?

Thanks,

- oshima

[Darin Fisher]

OK

 

, but I never had time to work on this change so far. (I made one change to handle installed apps)

Chrome currently wait 500ms before "proceeding". For m12, I was looking for an easy fix

that allow me to remove this 500ms hack, but If you think we should spend time on replacing it

instead, I'm happy to punt it to m13.

It looks like Linux support for HTML5 online/offline events is not going to happen until M13.

I was just talking to adamk and eroman about that.

 

One difference in chromeos is that we shows 'sign up for broadband' message in the offline page

using extension. I assume the error page is just an html page, so this shouldn't be an issue?

Right.

-Darin

[oshima]

HTML5 online/offline events looks promising and I now convinced myself that I should just wait for that :)

crbug.com/7469 is the one I should watch, right? 

Thank you!

- oshima

[Darin Fisher]

Yes.  By the way, this is all hooked up and functional on Windows for Chrome 11.  So, if you want to try prototyping on Windows, it should give you a good preview of what is to come.  Or, you could just simulate the events on another platform.

-Darin