WebKit does not conform to the WebIDL spec that instructs that operations must be configurable if they're not annotated as unforgeable[1]. WebKit's WebIDL implementation does not yet support the Unforgeable attribute, so all the operations should be made configurable until support for unforgeable operations is added. I'll try to do that in separate steps: 1. Add two no-op IDL attributes, OperationsNotDeletable and NotDeletable. 2. Deploy the OperationsNotDeletable attribute on all the interfaces. 3. Modify the JSC bindings generator to make all the operations configurable unless either the operation is annotated with the NotDeletable attribute or the operation's interface is annotated with the OperationsNotDeletable attribute. This would preserve the current behavior up to this point. 4. Start removing the OperationsNotDeletable attribute off the interfaces after checking conformity with other browsers and running the changes through the test suites. If any previous behavior should be preserved on specific operations, those operations would get annotated with the NotDeletable attribute. 5. Remove support for both attributes and the two attributes themselves after the transition is complete. [1] http://dev.w3.org/2006/webapi/WebIDL/#es-operations
Handling the addition of the two attributes in bug #122217.
This seems like a good plan. Do we have any idea of what operations will need to be marked unforgeable? How different is unforgeable from not-deletable? Should we start marking things unforgeable now even though it’s a no-op for now?
(In reply to comment #2) > Do we have any idea of what operations will need to be marked unforgeable? At the moment the Unforgeable attribute is only used on a couple of attributes on the Window interface and on the whole Location interface. http://www.w3.org/html/wg/drafts/html/CR/browsers.html#the-window-object http://www.w3.org/html/wg/drafts/html/CR/browsers.html#the-location-interface I couldn't find any operation declarations that are annotated with that IDL attribute, so there's nothing to handle specifically in that regard under the scope of this bug. > How different is unforgeable from not-deletable? Unforgeable attributes and operations are 'non-configurable and will exist as an own property on the object itself rather than on its prototype'. Their identifiers also mustn't clash with any other attributes or operations on the interface or any of its inherited or consequential interfaces. http://dev.w3.org/2006/webapi/WebIDL/#Unforgeable > Should we start marking things unforgeable now even though it’s a no-op for now? It would probably be better to add proper support for the attribute, but in the similarly cautious steps I'll be taking here.
Step 2, adding the OperationsNotDeletable attribute to all the relevant interfaces, is dispersed over 12 bugs: - bug #122269 covers interfaces under Source/WebCore/xml/, - bug #122270 covers interfaces under Source/WebCore/workers/, - bug #122271 covers interfaces under Source/WebCore/dom/, - bug #122272 covers interfaces under Source/WebCore/storage/, - bug #122273 covers interfaces under Source/WebCore/plugins/, - bug #122274 covers interfaces under Source/WebCore/loader/appcache/, - bug #122275 covers interfaces under Source/WebCore/fileapi/, - bug #122276 covers interfaces under Source/WebCore/css/, - bug #122278 covers interfaces under Source/WebCore/page/, - bug #122279 covers interfaces under Source/WebCore/svg/, - bug #122280 covers interfaces under Source/WebCore/html/, - bug #122281 covers interfaces under Source/WebCore/Modules/. I didn't change interfaces under Source/WebCore/bindings/scripts/test/, Source/WebCore/testing/ and Source/WebCore/inspector/ as those interfaces are not Web-facing (as a part of the Web platform). I'm not 100% the Inspector interfaces can immediately switch to having configurable operations, but I'm not aware of anything to test the change-in-behavior against.
I've used a script to annotate all the interfaces, so the patches also annotate interfaces that perhaps don't declare any operations. This is done simply to stay on the safe side and avoid any operation being added to an un-annotated interface before the generator is modified and subsequently changing the behavior of that operation without the conformity check.
(In reply to comment #5) > I've used a script to annotate all the interfaces, so the patches also annotate interfaces that perhaps don't declare any operations. Lets try to catch and remove those during the review process.
I am working on a browser privacy tool and have run into issues because window properties such as cookies and localStorage are not configurable as they are in Chrome and Firefox. So I am curious if there is a way I can help resolve this issue and 122018? (https://bugs.webkit.org/show_bug.cgi?id=126522) It looks like the latest source already has OperationsNotDeletable removed for the relevant operations, but they are still not configurable in the latest nightly builds. I have not previously contributed to WebKit, but I am happy to dive into the code if it would help. I wanted to check in first, so I can coordinate with others working on this issue. Also, I wanted to ensure that this open bug is simply waiting for code and patches would be helpful vs. say being blocked by a separate policy/security discussion that needs to be worked out first. Thanks.
Ignore my last comment, because after more research I do see that the changes listed in this bug are reflected in the nightly builds but only affect operations, not attributes. For example, the following are now configurable: Object.getOwnPropertyDescriptor(Storage.prototype,'setItem') Object.getOwnPropertyDescriptor(Window.prototype,'openDatabase') However, the following are still not configurable: Object.getOwnPropertyDescriptor(window,'localStorage') Object.getOwnPropertyDescriptor(Document.prototype,'cookie') document.cookie not being configurable appears related to the same underlying issue reported in bug 122018. And window.localStorage appears to be not configurable because it is not marked as [Replaceable], so I will follow up with these issues elsewhere.
All operations are configurable these days.