[Webkit-unassigned] [Bug 77854] XMLHttpRequest status & statusText should be 0 & "" following an abort()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=77854





--- Comment #13 from Mark Toller <mark.toller at samsung.com>  2012-10-19 12:19:59 PST ---
(In reply to comment #12)
> As you said, this looks like a duplicate of bug 54162. Why did you choose to continue work in a separate patch?

A number of reasons actually:

1) This is a bug that actually occurred on our device in the field, so it's a fix we are likely to roll out.
2) It matches the spec, and also the behaviour of Opera re: status and statusText being 0 & "".
3) Internet Explorer throws (incorrectly I believe) an exception when accessing status or statusText after the abort() 
   in this case (but certainly doesn't return values prior to the abort() call).
4) The other bug (54162) tries to fix all outstanding issues to match the spec (throwing exceptions, etc), and 
   someone said it might be better to split and fix the issues seperately. As I was fixing this anyway for our SW, it 
   seemed like the sensible option.

> The difficult part in moving it forward is not just implementing what a spec says. We need to make sure that we don't break sites that users depend on. With over 80% mobile market share belonging to WebKit, any change like this has a big chance of being bad for users and for WebKit, because authors don't even test with other engines.

I can appreciate that. I'm coming from the view that this was reported to us as a defect. I can't see the 
use case for being able to check what status and statusText were before an abort() was called (after all, 
the application could check before calling abort()). Following the call to abort(), the data is no longer 
available, and signalling DONE and status == 200 can (and in our case did) cause the application handler to 
behave as if it had succeeded.

How *do* you go about checking that changes like this don't break sites users depend on?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.