[webkit-reviews] review denied: [Bug 72154] Synchronous XHR in window context should not support new XHR responseTypes or withCredentials : [Attachment 119854] Patch

[bugzilla-daemon at webkit.org]

Alexey Proskuryakov <ap at webkit.org> has denied Jarred Nicholls
<jarred at webkit.org>'s request for review:
Bug 72154: Synchronous XHR in window context should not support new XHR
responseTypes or withCredentials
https://bugs.webkit.org/show_bug.cgi?id=72154

Attachment 119854: Patch
https://bugs.webkit.org/attachment.cgi?id=119854&action=review

------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
Discouraging use doesn't mean that we should break existing callers. Unlike
Mozilla and Opera engines, WebKit is widely used for non-Web content (and
that's an explicit goal of the project). It's also more commonly used with
walled garden content.

As far as web content is concerned, I did a quick Google search, and
withCredentials is widely used, including by libraries such as jQuery and
mooTools. Said libraries use it for decisions that would be icky to make based
on disabled functionality, even if that doesn't directly render results
invalid. It just adds too much complexity to the Web when you study and debug
code like the below:

// Does this browser support crossDomain XHR requests
jQuery.support.cors = testXHR && ( "withCredentials" in testXHR );

In fact, looking at those search results, I'm slightly less supportive of this
idea than before. We engine vendors have little say in whether to discourage
sync requests, it's library vendors who do. Since new responseTypes are
basically syntactic sugar, they can work with or without engine support. It
might be good to demonstrate our position, however with understanding that
benefits will be indirect if any, while damage will be direct.

> Going for the whole tamale here...

Changes that have the potential of breaking sites should be done separately to
ease finding the culprit later. That's the case for most kinds of changes, in
fact.