Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null

On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>>> Adam Barth:
>>>> > WebKit is looser in this regard.  We probably should change the
>>>> > default for new IDL, but it's a delicate task and I've been busy.  :(
>>>
>>> What about for old IDL?  Do you feel that you can make this change
>>> without breaking sites?  One of the “advantages” of specifying the
>>> looser approach is that it’s further down the “race to the bottom” hill,
>>> so if we are going to tend towards it eventually we may as well jump
>>> there now.
>>
>> I can't remember getting a single bug filed on Geckos current
>> behavior. There probably have been some which I've missed, but it's
>> not a big enough problem that it's ever been discussed at mozilla as
>> far as I can remember.
>
> Unfortunately, there's a bunch of WebKit-dominate content out there
> that folks are afraid to break.  We discussed this topic on some bug
> (which I might be able to dig up).  The consensus was that the value
> in tightening this for old APIs wasn't worth the compat risk (e.g., in
> mobile and in Mac applications such as Dashboard and Mail.app).
>
> For new APIs, of course, we can do the tighter things (which I agree
> is more aesthetic).  It mostly requires someone to go into the code
> generator and make it the default (and then to special-case all the
> existing APIs).  I'd like to do that, but it's a big job that needs to
> be done carefully and I've got other higher priority things to do, so
> it hasn't happened yet.

Here's the bug:

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

Sample opinion from one of the project leaders:

[[
Like other such sweeping changes, it’s highly likely there is some
content unwittingly depends on our old behavior. All a programmer has
to do is forget one argument to a function, and the program gets an
exception whereas before it would keep running. If it’s code or a code
path that was never tested with engines other than WebKit then this
could easily be overlooked.

Thus this change is almost certain to break "Safari-only" code paths
or even "WebKit-only" ones on at least some websites, Dashboard
widgets, Mac OS X applications, iPhone applications, and iTunes Store
content. Other than that, I’m all for it!
]]

Adam


>>> We saw that happen with addEventListener.
>>
>> The reason we made the last argument optional for addEventListener
>> wasn't that we had compatibility problems, but rather that it seemed
>> like a good idea as the argument is almost always set to false, and
>> being the last argument, making it optional works great.
>>
>> The fact that webkit already had this behavior was only discussed tangentially.
>>
>>> Jonas Sicking:
>>>> This is why it surprises me of WebIDL specifies WebKit behavior as the
>>>> compliant behavior as Cameron seems to indicate.
>>>
>>> In the spec right now it’s listed as an open issue, and it was the
>>> WebKit behaviour that I was going to specify to resolve the issue this
>>> week.  (So it’s not what the spec currently says.)  This is what I
>>> mentioned in
>>> http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html
>>> although I didn’t get any pushback then.  I am happy to keep discussing
>>> it but I would like to settle on a solution soon.
>>>
>>> So I guess you are arguing for “throw if too few arguments are passed,
>>> ignore any extra arguments”.
>>
>> Yes. In fact, unless someone can show that the web depends on the
>> currently specced behavior, I don't see a reason to change Gecko.
>>
>>> When we have overloads like
>>>
>>>  void f(in long x);
>>>  void f(in long x, in long y, in long z);
>>>
>>> we’d need to decide whether f(1, 2) throws or is considered a call to
>>> the first f with an extra, ignored argument.  The former seems more
>>> consistent to me.
>>
>> I agree, throwing seem better as it's more likely a bug on the callers
>> part. Or at the very least ambiguous which behavior they want which
>> means it's better to throw.
>>
>> / Jonas
>>
>

Received on Monday, 13 June 2011 07:20:51 UTC