999315 - alert(undefined) shows empty string

Status: VERIFIED FIXED

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

Description

[bugzilla77]

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

Comment 1

[YF (Yang)]

Why this is a bug?

I think the like:
alert()

Maybe you need:
alert("undefined")
alert(typeof undefined)

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

This is moderately unhelpful, but probably probably per spec.

Comment 3

[bugzilla77]

undefined should cast to "undefined"

Try it on Firefox 1 - 28 or Chrome 34 or Opera 20 or Explorer 11

Comment 4

[bugzilla77]

Or try document.write(undefined)

Why alert is casting now (FF 29) to empty string?
document.write cast to "undefined".

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[bugzilla77]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[YF (Yang)]

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

Comment 9

[Masatoshi Kimura [:emk]]

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?

Comment 10

[bugzilla77]

In webmastering alert(...) was the fastest way to check variable value. Now undefined is translated to empty string, and life is more complicated.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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 "".

Comment 12

[Boris Zbarsky [:bzbarsky]]

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...

Comment 13

[(no longer active)]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

console.log is a totally different situation, since the IDL there is "any..." and all the processing is in the implementation.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I raised a spec issue at https://www.w3.org/Bugs/Public/show_bug.cgi?id=25686

Comment 16

[Boris Zbarsky [:bzbarsky]]

Attachment: Revert alert(undefined) to showing the string "undefined" again, like it used to, pending the spec getting sorted out

Comment 17

[Boris Zbarsky [:bzbarsky]]

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 18

[Peter Van der Beken [:peterv]]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

It's already been changed in the spec.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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.

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c82b3f253337

Comment 22

[kenkon]

[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).

Comment 23

[alex_mayorga]

Verifying per comment 22.

Comment 24

[kenkon]

[testday-20140912]

For completeness, also verified on Firefox 33.0 beta 3.

Comment 25

[Camelia Badau [:cbadau], Desktop Test Engineering]

Marking verified on Firefox 33 based on comment #24.