Closed Bug 999315 Opened 6 years ago Closed 6 years ago
alert(undefined) shows empty string
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 Steps to reproduce: alert(undefined) Actual results: empty string Expected results: undefined
Why this is a bug? I think the like: alert() Maybe you need: alert("undefined") alert(typeof undefined)
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
This is moderately unhelpful, but probably probably per spec.
Component: Untriaged → DOM
Product: Firefox → Core
undefined should cast to "undefined" Try it on Firefox 1 - 28 or Chrome 34 or Opera 20 or Explorer 11
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Or try document.write(undefined) Why alert is casting now (FF 29) to empty string? document.write cast to "undefined".
The spec says: void alert(optional DOMString message = ""); and that's what we do. Note that alert with no arguments and explicitly passing undefined need to have identical behavior given that WebIDL, and that behavior is to show an empty string. Now it could be that the spec is wrong. Until the recent changes to treat undefined as not passed, the behavior here would have been different... But again note that the ES folks are pushing hard to have undefined always act the same way as not passed, so while we could work around this for now long-term alert() and alert(undefined) will simply not be distinguishable. Now of course maybe you're saying the former should also show "undefined"? In any case, this needs a spec change if we're going to change behavior.
IE, FF <29, Chrome, Opera alert function shows empty string only when arguments length is zero. When is defined first argument alert(undefined) default value is not given.
Yes, I know that. The point is, that's not what the spec says to do at the moment, so presumably the spec needs to change.
To bugzilla77, forgive me act rashly on the above, sorry. This behavior seems to occur on between 27 and 28, the return '' in Fx28. I do not know the relevant specifications and exact commit. so just FYI, Regression-range: Last good revision: abe6790a5dd8 (2013-11-01) First bad revision: 2f7593f81351 (2013-11-02) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=abe6790a5dd8&tochange=2f7593f81351 Last good revision: f0d363d72753 First bad revision: 2b4bd02c3300 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f0d363d72753&tochange=2b4bd02c3300
We know what bug causes the "regression", thank you. Yet another spec editor's whim. That said, do we really need to flip-flop the spec? Honestly I thought they were fully aware the change will break compatibility of some APIs more or less. Is this causing a issue in the real-world?
In webmastering alert(...) was the fastest way to check variable value. Now undefined is translated to empty string, and life is more complicated.
emk, I propose specifically changing the spec for alert(), not the general handling of undefined. Specifically, to this: void alert(); void alert(DOMString message); with prose saying the former alerts "".
Also, "Yet another spec editor's whim" is a gross mischaracterization of the outcome of a discussion with a number of people on public-script-coord...
If we end up working around this, we should probably apply the same workaround to console.log too, as I think the use case described in comment 10 applies similarly to that as well.
console.log is a totally different situation, since the IDL there is "any..." and all the processing is in the implementation.
I raised a spec issue at https://www.w3.org/Bugs/Public/show_bug.cgi?id=25686
Assignee: nobody → bzbarsky
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
My gut feeling is to just let this ride the trains instead of backporting, since we've already shipped this for two releases, but this would be a pretty simple backport too.
Comment on attachment 8421847 [details] [diff] [review] Revert alert(undefined) to showing the string "undefined" again, like it used to, pending the spec getting sorted out Review of attachment 8421847 [details] [diff] [review]: ----------------------------------------------------------------- I usually signaled that we're not following the spec by having a commented-out line that has the spec's version. If this is getting changed soon in the spec then nevermind.
Attachment #8421847 - Flags: review?(peterv) → review+
It's already been changed in the spec.
https://hg.mozilla.org/integration/mozilla-inbound/rev/c82b3f253337 Not planning to uplift this for the moment, but if someone thinks otherwise, please let me know.
Whiteboard: [need review]
Status: ASSIGNED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
[bugday-20140820] Reproduced on: Firefox 31.0 Verified on: Firefox 32.0 Beta 8 (20140818191513) Nightly 34.0a1 (20140820030202) Old results: Empty popup. New Results: Popup contains "undefined" string (without quotes).
Verifying per comment 22.
[testday-20140912] For completeness, also verified on Firefox 33.0 beta 3.
You need to log in before you can comment on or make changes to this bug.