Closed
Bug 999315
Opened 11 years ago
Closed 10 years ago
alert(undefined) shows empty string
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla32
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: 11 years ago
Resolution: --- → INVALID
Comment 2•11 years ago
|
||
This is moderately unhelpful, but probably probably per spec.
Component: Untriaged → DOM
Flags: needinfo?(bzbarsky)
Product: Firefox → Core
Reporter | ||
Comment 3•11 years ago
|
||
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 → ---
Reporter | ||
Comment 4•11 years ago
|
||
Or try document.write(undefined) Why alert is casting now (FF 29) to empty string? document.write cast to "undefined".
![]() |
Assignee | |
Comment 5•11 years ago
|
||
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)
Reporter | ||
Comment 6•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 7•11 years ago
|
||
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
Comment 9•11 years ago
|
||
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
Reporter | ||
Comment 10•11 years ago
|
||
In webmastering alert(...) was the fastest way to check variable value. Now undefined is translated to empty string, and life is more complicated.
![]() |
Assignee | |
Comment 11•11 years ago
|
||
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 "".
![]() |
Assignee | |
Comment 12•11 years ago
|
||
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•11 years ago
|
||
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.
![]() |
Assignee | |
Comment 14•11 years ago
|
||
console.log is a totally different situation, since the IDL there is "any..." and all the processing is in the implementation.
![]() |
Assignee | |
Comment 15•10 years ago
|
||
I raised a spec issue at https://www.w3.org/Bugs/Public/show_bug.cgi?id=25686
![]() |
Assignee | |
Comment 16•10 years ago
|
||
Attachment #8421847 -
Flags: review?(peterv)
![]() |
Assignee | |
Updated•10 years ago
|
Assignee: nobody → bzbarsky
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
![]() |
Assignee | |
Comment 17•10 years ago
|
||
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.
![]() |
Assignee | |
Updated•10 years ago
|
Whiteboard: [need review]
Comment 18•10 years ago
|
||
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+
![]() |
Assignee | |
Comment 19•10 years ago
|
||
It's already been changed in the spec.
![]() |
Assignee | |
Comment 20•10 years ago
|
||
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]
Comment 21•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c82b3f253337
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Updated•10 years ago
|
QA Whiteboard: [good first verify]
Comment 22•10 years ago
|
||
[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•10 years ago
|
||
Verifying per comment 22.
Status: RESOLVED → VERIFIED
status-firefox31:
--- → affected
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
status-firefox34:
--- → fixed
Whiteboard: [bugday-20140820]
Updated•10 years ago
|
Comment 24•10 years ago
|
||
[testday-20140912] For completeness, also verified on Firefox 33.0 beta 3.
Comment 25•10 years ago
|
||
Marking verified on Firefox 33 based on comment #24.
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•