Closed Bug 539488 Opened 16 years ago Closed 16 years ago

var statements for existing, read-only/permanent properties should not be errors (http://myuh.hawaii.edu/cp/home/loginf is blank)

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
blocking2.0 --- alpha1+

People

(Reporter: satoru, Assigned: Waldo)

References

()

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100113 Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100113 Minefield/3.7a1pre This site http://myuh.hawaii.edu/cp/home/loginf doesn't show anything with Minefield. This started with 01-12-2010 build. Reproducible: Always Steps to Reproduce: 1. Simple access http://myuh.hawaii.edu/cp/home/loginf 2. Nothing show up. 3. No problem with the latest version of Firefox Actual Results: Web page doesn't show up Expected Results: Web page show sup
Confirmed with latest trunk on Windows Vista. Is caused by one of the JavaScript checkins: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=502ed2576efc&tochange=cd2559411e26
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Version: unspecified → Trunk
The problem is still present in the latest tracemonkey.
Let's put the URL in the summary to make it distinctive.
Summary: This site doesn't show anything. → This site ( http://myuh.hawaii.edu/cp/home/loginf ) doesn't show anything.
I bisected the regression to here: changeset: 36848:bf7016ea5dba user: Jeff Walden <jwalden@mit.edu> date: Thu Jan 07 00:17:10 2010 -0600 summary: Support embedding of |undefined| in lookupswitch, needed to fix bustage in a Mochitest where use of |case undefined| results in that value being embedded in the lookup table, now that |undefined| is an immutable global property. Anticipatory r=jorendorff, real review on this coming soon...
Awesome, first blood to me! I'll look at this first thing tomorrow morning.
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
http://myuh.hawaii.edu/js/clientsniffer.js contains a top-level |var undefined|, which we treat as trying to redeclare a constant. Looking at ES5 to see what we should be doing here, I kind of doubt this is correct...
Yeah, I don't think current behavior is right. |var foo| where |foo| is a non-writable, non-configurable property, according to 10.5 Declaration Binding Instantiation, should do nothing, because the HasBinding call in step 8b returns true.
Blocks: es5
blocking2.0: --- → ?
Summary: This site ( http://myuh.hawaii.edu/cp/home/loginf ) doesn't show anything. → var statements for existing, read-only/permanent properties should not be errors (http://myuh.hawaii.edu/cp/home/loginf is blank)
This also affects the Flickr Organizer (http://www.flickr.com/photos/organize/).
Attached patch PatchSplinter Review
Attachment #422617 - Flags: review?(jorendorff)
Attachment #422617 - Flags: review?(jorendorff) → review+
http://hg.mozilla.org/tracemonkey/rev/a19af25a5ddc Incidentally, for those not following closely, the test in that push/patch is probably one of SpiderMonkey's more "special" tests. :-) The non-boilerplate portion consists entirely of: var undefined;
Whiteboard: fixed-in-tracemonkey
Target Milestone: --- → mozilla1.9.3a1
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
blocking2.0: ? → alpha1
Depends on: 632003
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: