558972 - deprecate XMLHttpRequest.open(method, url, false), i.e. synchronous XMLHttpRequest

Status: RESOLVED DUPLICATE of bug 969671

(Core :: DOM: Core & HTML, enhancement)

Description

[timeless]

https://developer.mozilla.org/En/Using_XMLHttpRequest
> Note: You shouldn't use synchronous XMLHttpRequests because, due to the
> inherently asynchronous nature of networking, there are various ways memory
> and events can leak when using synchronous requests.

let's deprecate it....

Comment 1

[timeless]

Attachment: proposal

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Eh :)

This must go via WebApps WG.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 438656 [details] [diff] [review]
proposal

Clearing the review request for now.

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Anne, what do you think?

Comment 5

[Anne (:annevk)]

Apart from within Web Workers I don't see harm in warning authors about its problems. I doubt you can remove it altogether though.

Comment 6

[Pomax]

I would like to raise a serious concern here - I see firefox nightly now reports sync xmlhttprequest as deprecated, but this feels like a step towards making the web harder for people to play with, without a justifiable reason for it: is it bad practice? probably. But should we, as mozilla, decide that people should therefore not be allowed to even try this and learn why it's bad, but (and this is important) not erroneous or dangerous to the browser?

That feels like overstepping our boundaries. There might be a whatwg spec but part of our responsibility here is to not blindly follow spec, but to be critical about what our decisions mean for the rest of the world, specifically people who are starting to play with the web. Forcing async xmlhttprequest is a great way to force people to first become webdevs, before they can write code that xmlhttprequests data in. That feels wrong, we should not be laying down the law here =)

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Synchronous XHR in the main thread is a bad API and it has 
"detrimental effects to the end user's experience". It blocks users input.
All the browser vendors agree on this matter.

Some more background 
http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx

Comment 8

[(no longer active)]

I second what Olli said here.  Everyone agrees that sync XHR was a mistake, it causes real performance/security problems for our users and we are very interested in removing it completely some day.

Comment 9

[Pomax]

If mistakes were reasons to lock things down, we would have killed off document.write and its ilk years ago, so just because it performs suboptimal and we, as browser maker, would like people to stop using it, does not mean that making that decision is a good idea.

Advocate using it off thread by all means. People who known about and understand web workers will be delighted. And yes, of course, it causes real performance issues (I don't buy the security argument). But everyone who starts to learn JS is going to write shitty underperforming JS, and as Mozilla we should think really hard about taking away their ability to learn using an API that started off at least a little sensible. Removing part of an API is a big deal, and in this case I don't think you realise quite how much better at the web you are than the vast majority of internet users, especially those who are a little scared of the web, but are getting introduced to it by efforts like Kahn Academy or Mozilla's own webmaker programmes. Thinking async is hard. Thinking off thread is hard. Starting with a simple "var xhr, xhr.open(), xhr.send, 'immediately' get data back" is crucial to see before moving on to thinking asynchronously.

As a dev I'd love to scratch a lot of bad JS API, but as a user of the web, and a teacher of the web, and a Moz employee working on tools to get people to stop just consuming the web and instead help make it, making this change is close to dictatorial. "We don't like it, so we're taking it away from you and leaving you nothing in its place". That's not the Mozilla way, even if there's a whatwg spec: we usually question those and point out why they're not okay (in pretty much the manner I am doing here =)

Comment 10

[(no longer active)]

(In reply to comment #9)
> If mistakes were reasons to lock things down, we would have killed off
> document.write and its ilk years ago, so just because it performs suboptimal
> and we, as browser maker, would like people to stop using it, does not mean
> that making that decision is a good idea.

Sure.  But note that arguing for bad features to not get killed because other bad features exists is a circular argument.

> Advocate using it off thread by all means. People who known about and
> understand web workers will be delighted.

Not sure what async XHR has to do with workers.

> And yes, of course, it causes real
> performance issues (I don't buy the security argument).

Sorry, but the fact remains that it's exceedingly difficult to secure things in presence of nested event loops in a system as complex as a Web engine, so even if _you_ don't buy that argument, it doesn't make it go away.  :-)

> But everyone who starts
> to learn JS is going to write shitty underperforming JS, and as Mozilla we
> should think really hard about taking away their ability to learn using an API
> that started off at least a little sensible.

Writing underperforming code is one thing, writing code which halts the entire execution of everything on the page (and in the case of Firefox, the browser UI as well) while a network operation completes is a whole other thing.

> Removing part of an API is a big
> deal, and in this case I don't think you realise quite how much better at the
> web you are than the vast majority of internet users, especially those who are
> a little scared of the web, but are getting introduced to it by efforts like
> Kahn Academy or Mozilla's own webmaker programmes. Thinking async is hard.
> Thinking off thread is hard. Starting with a simple "var xhr, xhr.open(),
> xhr.send, 'immediately' get data back" is crucial to see before moving on to
> thinking asynchronously.

Mike, everyone agrees that synchronous code is easier to understand even for non-beginners.  But that is not the entire picture.  Having this API hurts every single one of our users every single time they visit a web page that uses it.  Web engines do not have a "beginners learning mode" where they can enable APIs that harm our end users but can enable people to learn things faster while they're learning about web development, so the trade-off we're going to have to make is whether we want to make it easier for people to learn web programming the first time versus the performance problems that everyone of our users will be subject to.  And given the fact that the async XHR API gives you an event based model which is a model that people new to web development have to get familiar with sooner or later, I don't think the scale tilts in favor of your side of the argument here.

> As a dev I'd love to scratch a lot of bad JS API, but as a user of the web,

You should definitely hate sync XHR as a user of the web because it makes your experience miserable and slow every day.

> and
> a teacher of the web, and a Moz employee working on tools to get people to stop
> just consuming the web and instead help make it, making this change is close to
> dictatorial. "We don't like it, so we're taking it away from you and leaving
> you nothing in its place". That's not the Mozilla way, even if there's a whatwg
> spec: we usually question those and point out why they're not okay (in pretty
> much the manner I am doing here =)

Sure, if we were doing that your objections were completely valid.  But you've got it backwards.  There are very real performance and security reasons why we want to eventually retire this API, and it has nothing to do with our personal preferences; there is a replacement for it in its place, and the existence or lack thereof of a whatwg spec is not a determining factor here.  So please stop accusing us of not doing things the Mozilla way, it's not nice to be on the receiving side of this.

Comment 11

[Masatoshi Kimura [:emk]]

FYI this is already landed as bug 969671.

Comment 12

[Pomax]

I apologise for coming off the way I did, it's just the frustation of always learning about these things after they've already been implemented. Over the years there's been a lot of changes in the interest of security and "this is better" that actually feel like browser makers taking away the freedom of the web, and this is just one small new thing in a long series of such changes, without any way for regular users to even know where to listen for the signs that this is going to happen in the future. Especially when it's always met with "sorry, we already implemented this, you're too late to object" it feels like I have no voice (and with me, many others) so the tone of these comments tends to be harsher than they reasonably should be. It's just super-frustrating.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Sync XHR being a bad API has been discussed for years at w3c and whatwg, and the MSDN link I gave is  3 years old. So it was finally time to add a warning about use of the horrible API which we
want to get rid of eventually - if possible. Removing support for the API won't happen anytime soon.

Comment 14

[(no longer active)]

(In reply to comment #12)
> I apologise for coming off the way I did, it's just the frustation of always
> learning about these things after they've already been implemented. Over the
> years there's been a lot of changes in the interest of security and "this is
> better" that actually feel like browser makers taking away the freedom of the
> web, and this is just one small new thing in a long series of such changes,
> without any way for regular users to even know where to listen for the signs
> that this is going to happen in the future.

I understand your frustration with not knowing about this sooner, but there is no way for someone to know about every change we make in Gecko unless they watch the commit log or something.  However, I would like to take issue with statements such as "browser makers taking away the freedom of the web".  Did you actually read the link that Olli mentioned?  Did you take the time to research why we think that sync XHR is a bad API?  Based on your accusation of us taking away the freedom of the web, I tend to think that you have not gained a good understanding of what the issues with this API are.  And if you have indeed done the research and still feel this way, then we need to agree to disagree here.  If you think spending time and effort to get people to not use harmful APIs like this in the interest of serving all of the users of the Web is taking freedom away from it, then fine, let's call it that, but I'd respectfully suggest that viewpoint is deeply flawed.

> Especially when it's always met
> with "sorry, we already implemented this, you're too late to object" it feels
> like I have no voice (and with me, many others) so the tone of these comments
> tends to be harsher than they reasonably should be. It's just
> super-frustrating.

This is you objecting, isn't it?  :-)  You definitely have a voice as everyone else does, but if after researching the core issue here you disagree with us, then it's just that, you disagreeing.  It doesn't mean that browser makers are trying to take away your freedom, they just disagree with you on what's more important to optimize for, an easy to use API which lets you learn web development for the first time versus optimizing the experience of the Web for all of its users.  That is the trade-off at hand, and I really don't think arguing for the first position without constructing a case of why those new developers are more important than everyone else is going to cause us to reconsider this.

Comment 15

[Pomax]

oh definitely, this was me objecting. And the reality check is much appreciated =)

Comment 16

[Thomas]

Can someone explain to me what the difference between submitting a page and doing a sync XHR? In both ways the page will hang until we get a response. Do you think there is there higher risk of a sync XHR will hang than for a normal page submit? If so, why?

Why don't you just let the browser handle sync XHR internally as async XHR, and then give the user a message if there is no response? I thought this was the way it always worked. This way you only have to handle "no response" from sync XHR once for all pages. Now you want the developers to do the same trivial programming hundreds of times, making code more complex with the risk of making an even worse experience for the user.

I think it's a huge mistake to deprecate sync XHR!