Bug 91964 – Add "webkitBackgroundRequest" property to XMLHttpRequest

• Status: RESOLVED
• Resolution: INVALID
• Component: Page Loading

[Sean Wang]

When the page is doing an interruptable background XHR, such as the Instant fast searching, or when the XHR is from an extension, we may allow the request failing quietly other than having it popping up a dialog such as the authentication dialogs. We may want to indicate the XMLHttpRequest running on the background mode explicitly.

[Sean Wang]

Created attachment 153748 [details]
patch

Mozilla have added a property "mozBackgroundRequest"

Some discussions from mozilla and chromium.
https://developer.mozilla.org/en/xmlhttprequest
https://bugzilla.mozilla.org/show_bug.cgi?id=383430
http://code.google.com/p/chromium/issues/detail?id=31582

[Joe Mason]

Comment on attachment 153748 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153748&action=review

> Source/WebCore/ChangeLog:10
> +        When set thewebkitBackgournd property to true, the XHR should not popup dialogs, it can fail

Typo: should be "the webkitBackground".  Also the commit message should always talk about "webkitBackgroundRequest" since that's the full name of the property.

> Source/WebCore/ChangeLog:15
> +        supported by some platforms which is needed by the new tests.

We should still write tests, and just skip them on platforms that don't support setHandlesAuthenticationChallenges

> Source/WebCore/ChangeLog:24
> +        * platform/network/blackberry/NetworkJob.cpp:

I think the BlackBerry-specific part of this should be in a separate patch.

[Alexey Proskuryakov]

This is a new feature, and as such needs to be discussed on webkit-dev first.

I personally think that we shouldn't implement this feature unless it makes its way to the spec. It's a very specialized handling of a rare edge case - if people want more control over authentication, it should not be through "background request".

Besides, it's up to debate whether XHR should ever be allowed to display authentication dialogs anyway.

> Mozilla have added a property "mozBackgroundRequest"

Note this: "Requires elevated privileges to access." And these requests have different semantics in that they are not associated with a frame.

[Adam Barth]

Comment on attachment 153748 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153748&action=review

I'm not sure I understand the use case.  We should just stop XMLHttpRequest from poping up HTTP auth dialogs all the time.

> Source/WebCore/platform/network/ResourceRequestBase.h:194
> +        bool m_loadInBackground : 1;

You can't add state to ResourceRequestBase that can't be represented in an NSURLRequest.  Yes, that's lame, but it's a current design constraint.

[Liam Quinn]

(In reply to comment #4)
> We should just stop XMLHttpRequest from poping up HTTP auth dialogs all the time.

That sounds reasonable to me, but it does go against http://www.w3.org/TR/XMLHttpRequest/, which says "If authentication fails, XMLHttpRequest origin and the request URL are same origin, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password."

Current versions of Chrome, Firefox, and Opera all prompt the user on a 401 from XHR. Safari does not.

[Alexey Proskuryakov]

Are you testing with a synchronous request? With regular async ones, Safari does prompt too.

[Liam Quinn]

(In reply to comment #6)
> Are you testing with a synchronous request? With regular async ones, Safari does prompt too.

Yes, you're right. I was testing with a synchronous request. With async, Safari does indeed prompt.

[Charles Wei]

Let's just fail the HTTP authentication for the XHR and other sub-resources instead of prompting the user for credentials, if there's no credentials stored for the resource.