Closed Bug 999315 Opened 6 years ago Closed 6 years ago

alert(undefined) shows empty string

Categories

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

29 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla32
Tracking Status
firefox31 --- affected
firefox32 --- verified
firefox33 --- verified
firefox34 --- verified

People

(Reporter: bugzilla77, Assigned: bzbarsky)

References

Details

(Whiteboard: [bugday-20140820])

Attachments

(1 file)

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
Flags: needinfo?(bzbarsky)
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.
Flags: needinfo?(bzbarsky)
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?
Blocks: 882541
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.
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.
Whiteboard: [need review]
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.
Flags: in-testsuite?
Whiteboard: [need review]
https://hg.mozilla.org/mozilla-central/rev/c82b3f253337
Status: ASSIGNED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
QA Whiteboard: [good first verify]
[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.
Status: RESOLVED → VERIFIED
Whiteboard: [bugday-20140820]
[testday-20140912]

For completeness, also verified on Firefox 33.0 beta 3.
Marking verified on Firefox 33 based on comment #24.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.