When I was fixing the patch for bug 13517 so that it would past fast/js/const, I realized that const is currently handled incorrectly. A variable that is declared with either a var declaration or a const declaration can be redeclared (and given a new value) with const, which is against <http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:const>.
Created attachment 15503 [details] Test case Here is a test case. I have a pretty good idea of a patch, but it depends on the fix for bug 13517, so I will wait until that is resolved.
Confirmed with a local debug build of WebKit r24285 with Safari 3.0 (522.12) on Mac OS X 10.4.10 (8R218). Opera 9.21.3678 fails as well.
*** Bug 19194 has been marked as a duplicate of this bug. ***
*** Bug 21700 has been marked as a duplicate of this bug. ***
consts can also be deleted. Which is against Mozilla's spec. Attempting to delete a const should return false and fail (not throwing any errors though).
Created attachment 29789 [details] testcase that also tests deleting a const
Oh yeah, so much is wrong with our implementation of 'const'. In practice, it doesn't matter at all, because nothing depends on the correct behaviour. We should fix it some day, but I don't think it is a priority right now given the other bugs that are open. If someone knows of a site that this breaks, mention it here and I'll try to fix it.
(In reply to comment #7) IMO, it's pretty important if you want to make library that, if a site scumbs to an XSS flaw, the library reports a bug on itself on a page. For example: const reportXSSFlawedPage = function() { do_some_stuff_with(location.href) }; In Firefox, the website will report an error to the admin so he can get the library fixed ASAP. In WebKit, the XSS attack knows about the "reportXSSFlawedPage" function, and overwrites it. The admin doesn't find out about the XSS flaw until quite a few users have been affected.
*** Bug 21701 has been marked as a duplicate of this bug. ***
Our const behavior currently doesn't respect any spec, and therefore can do whatever it wants. :-) Our intention is to fix this by replacing our current implementation with one that implements Harmony block scoped const; this bug should be subsumed as a part of that change. *** This bug has been marked as a duplicate of bug 31813 ***