about adding timeout support in network stack for XMLHttpRequest Level 2 timeout attribute

[Wei, James]

http://www.w3.org/TR/XMLHttpRequest/#the-timeout-attribute

 

XHR2 introduces timeout attribute to client and several browsers already support it.

 

In order to support it in Chromium, we have two choices:

 

1. Implement it in WebKit use current network stack. Just like https://bugs.webkit.org/show_bug.cgi?id=103251

2. Add timeout support in chromium network stack.

 

Both implementation will follow the same process:

1. start a timer when sending request out.

2. cancel the request if timer fired and failed the request with timeout error.

 

Any idea for it?

 

 

Best Regards

 

James

 

 

[Adam Barth]

> If there is an associated XMLHttpRequest document and the synchronous flag is set, throw an "InvalidAccessError" exception and terminate these steps.

It looks like this feature is disabled for synchronous XHRs. That
seems odd given that it's the one use case that the web site can't
implement itself.

Adam

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

[Wei, James]

There are some discussion when implemented this feature in Mozilla Firefox attached at the end.

I tried to find some threads in W3C mailing list for this issue but failed. there should be such discussion when making the spec to explicitly exclude sync timeout.

https://bugzilla.mozilla.org/show_bug.cgi?id=525816#c36
I don't think we have discussed limiting timeout to just asynchronous. Timeout is in fact mostly useful in sync mode since in asynchronous you can simply call .abort from a timeout.

I don't think we'll be successful in forcing everyone off of using the sync API. In the cases where we are not it's good for users if the timeout feature is available to prevent extended UI freeze.


https://bugzilla.mozilla.org/show_bug.cgi?id=525816#c37
ATM, I'm strongly against adding timeout for sync. That would make sync behave perhaps a bit
better in some cases, but would also hint that it is ok to use sync XHR.
Even 50ms sync XHR is bad for the UI.

Timeout is useful for async too. No need to create separate timers for all the XHRs.

https://bugzilla.mozilla.org/show_bug.cgi?id=525816#c38
I honestly don't think people care about what "hints" we give them. If you're worried about giving the wrong impression we can always add a warning in the console every time a sync XHR is done (no matter if .timeout is used or not).

The whole reason we don't like sync XHR is that it gives users a bad experience. .timeout can't fix that, but can improve it.

In any case, you need to convince the WG and not just me that .timeout shouldn't work for sync.

https://bugzilla.mozilla.org/show_bug.cgi?id=525816#c39
I don't see *any* reasons to add any new features to sync XHR.

And I did discuss about this with Anne, and he was going to change the spec.

Best Regards

James

[Adam Barth]

These folks are right that we're trying to encourage developers to use
async XHR by limiting most new features to async. This case is
something of an oddity in that it's a feature that might actually help
sync XHR suck less.

Adam

[Ojan Vafai]

I'm torn on this. On the one hand, it could make sync XHR less awful. On the other hand, I can easily imagine more people using it because they are like "blocking for 200ms isn't bad since a user can't perceive less that" and feeling more comfortable using it (e.g. see https://www.google.com/?q=200ms%20user%20perception).

[Darin Fisher]

Implementation note:  Sync XHR is currently implemented browser-side in Chrome.  So, if we wanted to support a timeout for Sync XHR, we'd need to pass that through the WebURLRequest so that the browser-side could enforce the timeout.

My personal opinion is that client-side timeouts applied to network requests don't make much sense.  There are a variety of things that can delay network requests.  They can even be delayed waiting on user input (e.g., HTTP auth prompt) or browser extensions might delay them.  They can also be delayed waiting for the underlying network to startup (e.g., a modem needs to re-connect).

I think we should only support client-side timeout applied to XHR in so far as other browsers have implemented it.  If they hadn't already done so, then I would argue that it is not needed.  Certainly it is possible to implement a client-side timeout for Async XHR just using setTimeout and XHR.abort().

-Darin

[Eric Roman]

Synchronous XHRs causing hangs is a very real problem for Chrome users: It is one of the top 10 causes of renderer crashes.

(Scenario: webpage hangs due to sync xhr ==> user gets prompted with an unresponsive webpage dialog --> user kills renderer --> tears)

The worst offenders are Chrome extensions. Most hangs are coming from content scripts injected into facebook.com and youtube.com. For instance, the Avast extension.

Independent of whether or not we support timeouts for sync XHRs, we can dramatically improve the user experience by giving users the option to abort hung sync XHRs!

I have filed this as: https://code.google.com/p/chromium/issues/detail?id=164665

Basically the proposal is for the hung webpage dialog to indicate when the page is hung due to a sync XHR, show what the URL being waited on is, and give the option to abort it. This lets users recover from what today is a very bad situation, and would put pressure on site/extension authors to fix their act (since we are now blaming them for the hang).

Cheers.

On Wed, Dec 5, 2012 at 10:04 PM, Ojan Vafai <oj...@chromium.org> wrote:

[PhistucK]

Those were very disappointing statistics and your idea is very nice.

I see one problem here, in the content script case, with content scripts that inject scripts into the world/context of the page and make synchronous through them (I am not sure how common that is, of course, but I am just noting that).

Sure, you can blame the source of the script, if it is indeed injected as a <script src> from the chrome-extension scheme and not as an inline script or other external script source. But that does not cover all of the cases and you can lead users into thinking something is wrong with a website when it really is not the fault of the website, but some badly coded extension.

When you have accurate information (the script is part of the original source of the page, or no extension is running), it is safe to blame the website, but when you do not have accurate information, you can blame innocents.

Perhaps there are ways to deal with that as well, of course. It just needs to be thought out.

I guess an infobar could be used to unobtrusively alert the user.

☆PhistucK

[Ojan Vafai]

On Thu, Dec 6, 2012 at 12:51 PM, Eric Roman <ero...@chromium.org> wrote:

Synchronous XHRs causing hangs is a very real problem for Chrome users: It is one of the top 10 causes of renderer crashes.

(Scenario: webpage hangs due to sync xhr ==> user gets prompted with an unresponsive webpage dialog --> user kills renderer --> tears)

Ouch.

 

The worst offenders are Chrome extensions. Most hangs are coming from content scripts injected into facebook.com and youtube.com. For instance, the Avast extension.

Can we disable sync XHR from the next version of extensions? Do we already?

 

Independent of whether or not we support timeouts for sync XHRs, we can dramatically improve the user experience by giving users the option to abort hung sync XHRs!

I have filed this as: https://code.google.com/p/chromium/issues/detail?id=164665

Basically the proposal is for the hung webpage dialog to indicate when the page is hung due to a sync XHR, show what the URL being waited on is, and give the option to abort it. This lets users recover from what today is a very bad situation, and would put pressure on site/extension authors to fix their act (since we are now blaming them for the hang).

Can we just put a lower, hard timeout on sync XHRs? I'm thinking something on the order of 1-5 seconds. It's still a terrible experience, but much better.

[Scott Hess]

Unfortunately, extensions can inject stuff into the page, so in the
limit we can't disable sync XHR for extensions.

That said, we should be able to track this, so we could see whether a
particular extension is correlated with hanging sync XHRs. Then we
could ???. The ??? is always the problem, I guess.

-scott

[Ojan Vafai]

On Thu, Dec 6, 2012 at 1:25 PM, Scott Hess <sh...@chromium.org> wrote:

Unfortunately, extensions can inject stuff into the page, so in the
limit we can't disable sync XHR for extensions.

I don't believe this is true. Extensions get injected into an isolated world. In theory, they could cause existing code on the page to do a sync XHR if such code existed, but I think we could otherwise disallow it, which certainly is good enough.

[Dominic Mazzoni]

On Thu, Dec 6, 2012 at 1:28 PM, Ojan Vafai <oj...@google.com> wrote:

On Thu, Dec 6, 2012 at 1:25 PM, Scott Hess <sh...@chromium.org> wrote:

Unfortunately, extensions can inject stuff into the page, so in the
limit we can't disable sync XHR for extensions.

I don't believe this is true. Extensions get injected into an isolated world. In theory, they could cause existing code on the page to do a sync XHR if such code existed, but I think we could otherwise disallow it, which certainly is good enough.

I think it'd be hard to prevent an extension from injecting a <script> tag into the page, and in fact there are good reasons to do this - for example, content scripts can't access window.parentWindow, so some people have a content script inject a script into the page in order to find out whether it's in an iframe or not, or in order to communicate between iframes.

- Dominic

[Adam Barth]

On Thu, Dec 6, 2012 at 1:28 PM, Ojan Vafai <oj...@google.com> wrote:
> On Thu, Dec 6, 2012 at 1:25 PM, Scott Hess <sh...@chromium.org> wrote:
>> Unfortunately, extensions can inject stuff into the page, so in the
>> limit we can't disable sync XHR for extensions.
>
> I don't believe this is true. Extensions get injected into an isolated
> world. In theory, they could cause existing code on the page to do a sync
> XHR if such code existed, but I think we could otherwise disallow it, which
> certainly is good enough.

That's right. We keep track of whether it's an extension XHR so that
we can give it the extension's privileges. Blocking sync XHR in
content scripts would be easy from a technical point of view (putting
aside the compatibility issues).

Adam

[William Chan (陈智昌)]

On Thu, Dec 6, 2012 at 6:12 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, Dec 6, 2012 at 1:28 PM, Ojan Vafai <oj...@google.com> wrote:
> On Thu, Dec 6, 2012 at 1:25 PM, Scott Hess <sh...@chromium.org> wrote:
>> Unfortunately, extensions can inject stuff into the page, so in the
>> limit we can't disable sync XHR for extensions.
>
> I don't believe this is true. Extensions get injected into an isolated
> world. In theory, they could cause existing code on the page to do a sync
> XHR if such code existed, but I think we could otherwise disallow it, which
> certainly is good enough.

That's right.  We keep track of whether it's an extension XHR so that
we can give it the extension's privileges.  Blocking sync XHR in
content scripts would be easy from a technical point of view (putting
aside the compatibility issues).

What compat issues? Can't we just dictate that the next extension version requires it? So if you want goodies from the new APIs in a new extension version, you have to clean up your code?

Death to sync XHRs.

[Ojan Vafai]

On Thu, Dec 6, 2012 at 7:39 PM, William Chan (陈智昌) <will...@google.com> wrote:

On Thu, Dec 6, 2012 at 6:12 PM, Adam Barth <aba...@chromium.org> wrote:

On Thu, Dec 6, 2012 at 1:28 PM, Ojan Vafai <oj...@google.com> wrote:
> On Thu, Dec 6, 2012 at 1:25 PM, Scott Hess <sh...@chromium.org> wrote:
>> Unfortunately, extensions can inject stuff into the page, so in the
>> limit we can't disable sync XHR for extensions.
>
> I don't believe this is true. Extensions get injected into an isolated
> world. In theory, they could cause existing code on the page to do a sync
> XHR if such code existed, but I think we could otherwise disallow it, which
> certainly is good enough.

That's right.  We keep track of whether it's an extension XHR so that
we can give it the extension's privileges.  Blocking sync XHR in
content scripts would be easy from a technical point of view (putting
aside the compatibility issues).

What compat issues? Can't we just dictate that the next extension version requires it? So if you want goodies from the new APIs in a new extension version, you have to clean up your code?

Death to sync XHRs.

+1. Yes, you can still workaround it by appending a <script>, but it's a war of attrition. That will weed out some of the usage. 

I think Adam may have just been saying that we need to tie it to the next revving of the extension version.

[Wei, James]

Thank you all for your comments.

 

So do you have any preference for implementing client side timeout in Chromium or WebKit?

 

If you think client side timeout is a useful feature for chromium, then I can implement it in chromium.

 

Best Regards

 

James

[William Chan (陈智昌)]

FWIW, I'm personally against it. I think it's a bandaid for sync XHR. If people are going to change their code, they should do it right and make it async. Just my two cents.

[Chris Bentzel]

Which browsers support sync XHR timeouts - you mention Firefox. Are there others?

I share the same general desire to only allow this in if there are major web compat reasons.

[Ojan Vafai]

Filed http://crbug.com/165298 and http://crbug.com/165301.

On Thu, Dec 6, 2012 at 1:20 PM, Ojan Vafai <oj...@google.com> wrote:

[Wei, James]

I don’t mean sync XHR. I am NOT going to implement sync XHR timeout.

 

But for Async request client side timeout, should it be implemented in chromium side or webkit side? do you have any comments? Thanks

[Wei, James]

AFAIK, firefox doesn’t support Sync XHR timeout, but it supports Async XHR timeout.

 

And Opera also supports async XHR timeout. So I just want to implement Async XHR timeout firstly.  

 

But my question is that in order to support async XHR timeout, do we need to add the timeout feature to HTTP network stack in chromium and then implement async XHR timeout, or just implement it in WebKit using current network stack?

 

I implemented this feature in webkit https://bugs.webkit.org/show_bug.cgi?id=103251

 

And abarth thought this should be in network stack. So I bring this discussion here.

 

there was the same discussion when implementing XHR2 timeout with soup in GTK and EFL port and at last they decided to implement it in webkit and not change libsoup.

 

https://bugzilla.gnome.org/show_bug.cgi?id=682804  

 

some feedback from the developer of libsoup:

 

Dan Winship [libsoup developer] 2012-08-28 13:12:24 UTC

so, note that this would essentially boil down to g_timeout_add() +

soup_session_cancel_message(), and there's no reason webkit couldn't just do

that itself instead...

 

Dan Winship [libsoup developer] 2012-08-30 12:27:00 UTC

I guess it boils down to whether or not other apps are likely to need

per-message as opposed to per-session timeouts. And that doesn't seem like a

very common use case. So maybe it's better to just do it in WebKit.

Best Regards

 

James

[Wei, James]

http://www.w3.org/TR/XMLHttpRequest/#the-timeout-attribute

 

and W3C spec also indicates that we should only support async XHR client timeout. No Sync XHR timeout should be supported.

 

Best Regards

 

James

 

 

From: Wei, James
Sent: Tuesday, December 11, 2012 8:40 AM
To: 'William Chan (陈智昌)'
Cc: Adam Barth; Ojan Vafai; Scott Hess; ojan+...@google.com; Eric Roman; chromi...@chromium.org
Subject: RE: [chromium-dev] about adding timeout support in network stack for XMLHttpRequest Level 2 timeout attribute

 

I don’t mean sync XHR. I am NOT going to implement sync XHR timeout.

 

But for Async request client side timeout, should it be implemented in chromium side or webkit side? do you have any comments? Thanks

 

Best Regards

[Darin Fisher]

I would probably implement this in WebCore.  If CFNetwork has built-in support for timeouts, then that might suggest putting the implementation behind the ResourceHandle implementation.  I could easily imagine adding a timeout parameter to ResourceRequest.  For Chromium, I would probably implement that in chromium/ResourceHandle.cpp.  However, if CFNetwork does not have built-in support for timeouts, then I'd probably put the implementation directly in XMLHttpRequest.cpp since no other consumer of ResourceHandle needs this timeout support.

-Darin

[William Chan (陈智昌)]

Whatever you do, you don't want to implement it in the Chromium network stack. Our API for this is URLRequest. If you want to timeout, then set a timeout in the embedder and cancel the URLRequest (probably by deleting it). I see Darin's already provided guidance for how to do this in WebKit. I do not have a strong opinion about where else it's done as long as it's not the Chromium network stack. Cheers.

[Wei, James]

Willchan, darin,

 

Thank you for your suggestion. I will discuss with adam how to do it better in WebKit. Thanks.