webkitIntent cannot be assigned for some reason and is always null after assignment.
gbillock: In DOMWindowIntents.idl, should the webkitIntent attribute be really marked as readonly? Because of this, the JSC bindings generator does not generate a setter and does not do any shadowing. As a consequence, the webintents/web-intents-delivery-reuse.html test is failing for us. If I remove the "readonly" for the attribute, then the test is passing just fine. Is it really something that should be fixed in the JSC bindings generator?
Created attachment 143551 [details] Patch Here is a patch which removes the "readonly" keyword from the webkitIntent attribute so that it becomes truly replaceable with JSC. The patch also unskips the corresponding test case for EFL port. Note that in the whole source tree, there is no other IDL attribute which is both readonly and [Replaceable].
(In reply to comment #1) > gbillock: In DOMWindowIntents.idl, should the webkitIntent attribute be really marked as readonly? Because of this, the JSC bindings generator does not generate a setter and does not do any shadowing. > > As a consequence, the webintents/web-intents-delivery-reuse.html test is failing for us. If I remove the "readonly" for the attribute, then the test is passing just fine. Is it really something that should be fixed in the JSC bindings generator? Seems fine to me, but Adam is a better person to ask. I put readonly because when the internal object is returned, JS shouldn't be altering it -- since it is replaceable, they can just write their own. It sounds like JSC uses another mechanism to accomplish that, though.
Comment on attachment 143551 [details] Patch Ok.
Comment on attachment 143551 [details] Patch Clearing flags on attachment: 143551 Committed r118241: <http://trac.webkit.org/changeset/118241>
All reviewed patches have been landed. Closing bug.