Bug 25527

Summary: attempting to delete non-deletable properties on the String prototype returns incorrect value
Product: WebKit Reporter: Erik Corry <erikcorry>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: barraclough, oliver, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.4   

Description Erik Corry 2009-05-03 14:01:26 PDT
delete String.prototype.replace and delete String.prototype.toLowerCase have no effect in JSC.  This is causing compatibility issues with V8, Firefox and MSIE as detailed in http://code.google.com/p/chromium/issues/detail?id=1717
AFAIKS it is a violation of the spec, which doesn't list the DontDelete property for String.prototype.replace. Here is a test snippet:

<script>
delete String.prototype.replace;
alert("String.prototype.replace is " + ("foo".replace ? "not deletable" : "deletable"));
</script>

Result for JSC: not deletable
Result for other JS implementations: deletable

Tested in Safari Version 4 Public Beta (4528.16)
Comment 1 Erik Corry 2009-05-04 03:51:00 PDT
Further investigation of JSC reveals that delete returns true despite the fact that it doesn't work.  All the methods on String.prototype have the same issue.  In addition, the methods on Array.prototype and Date.prototype and the following properties on Math (not Math.prototype) have the same issues:

  "random", "abs", "acos", "asin", "atan", "ceil", "cos", "exp", "floor", "log",
  "round", "sin", "sqrt", "tan", "atan2", "pow", "max", "min",

The following properties are also on Math, but they work as intended (have
DONT_DELETE and READ_ONLY).

  "E", "LN10", "LN2", "LOG2E", "LOG10E", "PI", "SQRT1_2", "SQRT2"

Strangely, the functions on Object.prototype and RegExp.prototype, Boolean.prototype, Number.prototype and Function.prototype work fine.  They can be deleted, as can the properties on the global object (escape, unescape, etc) and String.fromCharCode (On String itself, not the prototype).
Comment 2 Oliver Hunt 2009-05-04 03:57:19 PDT
Looking at the chromium bug it would appear that making these properties deletable would cause a site regression, so i'm not sure why that's desired?
Comment 3 Erik Corry 2009-05-04 04:24:20 PDT
Because you would be following the standard and the behaviour of Firefox, MSIE, Chrome and Opera.   The site is obviously broken, deleting a property and then trying to use it.

If you decide not to fix the fact that deletion fails it would at least be nice to fix the incorrect return value from the delete operator.
Comment 4 Oliver Hunt 2009-05-04 04:29:50 PDT
Retitling bug to represent actual bug.

Will talk to brendan tomorrow to find out why the ECMA262-5 document doesn't specify deletability of standard properties, as i know there have been changes from ECMA262-3
Comment 5 Oliver Hunt 2009-05-04 04:34:04 PDT
(In reply to comment #3)
> Because you would be following the standard and the behaviour of Firefox, MSIE,
> Chrome and Opera.
A minor note would be not one of these browsers is standard compliant -- they will all have quirks to deal with some bugs they had in the past or have implemented to deal with sites that expect the quirks from other browsers.

Well except chrome of course.  But that's just embedding webkit so it gets all the quirk history of safari instead :D

As a fact of life you're going to need to accept that if you claim to be webkit you need to be quirk compatible with JSC.  (After all my understanding is that you implemented __defineGetter__ for the WebInspector, and __defineGetter__ is a quirk we originally added support for FFX compat.  Yay standards! \o/ )
Comment 6 Erik Corry 2010-03-29 01:07:37 PDT
This bug causes http://code.google.com/p/chromium/issues/detail?id=39662
Comment 7 Gavin Barraclough 2012-03-12 19:24:17 PDT
These properties all work correctly for me in ToT, please reopen if you can repro any issues here.

cheers, G.