This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html Multipage: http://www.whatwg.org/C#the-window-object Complete: http://www.whatwg.org/c#the-window-object Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: alert() needs two overloads so alert(undefined) can alert "undefined" Posted from: 63.245.221.34 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
People are asking for alert(undefined) to show "undefined". Current behavior in browsers: Chrome, Firefox 27 and earlier, IE11: alert() shows "" alert(undefined) shows "undefined" Firefox 28 and later, current spec: alert() shows "" alert(undefined) shows "" Safari 7: alert() shows "undefined" alert(undefined) shows "undefined" To get the Chrome/IE/old-Firefox behavior, the IDL needs to be: void alert(); void alert(DOMString message); with prose that says that the first overload uses "" as the message. To get the Safari behavior, the IDL can be: void alert(optional DOMString message = "undefined"); For now I'm switching Firefox to our old behavior over in https://bugzilla.mozilla.org/show_bug.cgi?id=999315
But note that the Safari behavior here is more JavaScripty in principle.
Just to chime in: Both the Firefox 28+ and Safari 7+ behaviors are reasonably JavaScriptey. Firefox 28+ behaves as if it were function alert(message = "") { message = String(message); // standard type coercion here } and Safari 7+ behaves as if it were function alert(message) { message = String(message); } If we can get away with either of those two that would be nice. Sounds like the Firefox 28+ behavior is a no-go though.
Right, to be clear I was comparing the Safari behavior to the Chrome/IE/old-Firefox behavior. The new-Firefox behavior is indeed reasonably JavaScripty, but seems to not be what people seem to want from this API.
And I personally would be OK with trying to switch Gecko to the Safari behavior.
If I define: void alert(); void alert(DOMString message); ...and then you pass the undefined value explicitly, it picks the DOMString overload? It doesn't pretend the argument was omitted?
I believe that is the current state of WebIDL, yes, and some other APIs rely on that.... Of course if we do the Safari behavior it's a nonissue.
Yeah, looks like Web IDL doesn't do anything to treat explicit "undefined"s as missing arguments. Ok. Do you want this for prompt() or confirm() too, or just alert()?
It's only come up as an issue for alert(), since people use that to examine the value. For prompt() and confirm() both "" and "undefined" are pretty much pointless given how the string is supposed to be used, so I don't have an opinion as to which we should do.
Ok. Thanks!
Checked in as WHATWG revision r8638. Check-in comment: for compat, apparently alert() should alert '' and alert(undefined) should alert 'undefined' http://html5.org/tools/web-apps-tracker?from=8637&to=8638
(I used the more widely implemented behaviour; I don't mind switching to another behaviour but we should get more vendors on board if we want to do that.)