BTW, I modeled my SharedWorker disabling after the code in JSDOMWindowCustom::audio() that disables the audio constructor on platforms that don't have MediaPlayer support. I think the runtime behavior of window.audio and window.SharedWorker should be identical in practice. Sam, it looks like you wrote JSDOMWindowCustom::audio() - do you see its behavior as unacceptable as well, or do you have some other code to prevent enumeration of window.audio that I can generalize for use for SharedWorkers too? -atw
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <[email protected]> wrote: > So, two weeks ago I sent an email on this thread stating exactly what I was > planning to do, To whit: > >>> > I do think that we ought to be returning undefined instead of null in those > cases, though, just to catch people who are accidentally using isUndefined() > utility functions from common libraries. It would not be hard to define some > kind of [mapNullToUndefined] custom attribute for the code generator. > <<< > > Maciej and AP both chimed in saying that disabling enumeration (i.e. > "SharedWorker in window") would be prohibitively hard, and giving a tacit OK > to my approach (my emphasis below): > > >>> > It would be pretty complicated to do that [disabling [LocalStorage in > window"] based on a runtime setting. You would need a custom getter for any > object that has properties which may appear or disappear based on settings. > This is *probably too complicated to be worth it*. Or at least, if we > added that level of code complexity I would begin to doubt the merits of > supporting runtime enabling of Web platform features. > <<< > > I'm surprised to see these objections coming up now, weeks after the > original discussion, and only after my patch has landed in the tree. That > said, I agree that in an ideal world, we'd hide window.audio, shared > workers, notifications, local storage, databases, session storage and any > other runtime/platform-disabled API from enumerations - I just agree with > Maciej that this isn't a hugely important issue, since these features are > only runtime-disabled while under development and so not widely available > anyway. > > Regardless, I don't think we should rush out to roll all of those features > out of the tree, and I certainly don't think we should be singling out > SharedWorkers or WebSockets - if we feel strongly that this needs to be > addressed, we can update all of those features accordingly. If people with > knowledge of the internals of V8 and JSC can chime in, we can discuss how > best to approach this. > > -atw > > > On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig <[email protected]> wrote: > >> Hi Folks, >> >> I am not happy with the way these runtime settings have been implemented >> so far as they break runtime detection using the technique we evangelize to >> developers, specifically, using the ("property" in window) method. A >> feature that is turned off at runtime should not be detectable at all, using >> any method (including Object.keys(), object.hasOwnProperty(), >> object.propertyIsEnumerable(), for-in enumeration, etc). I filed >> https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime >> switching code went in and was disappointed to see similarly buggy code go >> in for SharedWorkers with out this being fixed. >> Leaving this in the tree is likely to introduce compatibility issues so I >> would recommend that we roll out these changes if they cannot be fixed in a >> timely manner. >> >> -Sam >> >> On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher <[email protected]> wrote: >> >>> As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for >>> the Chromium project, we like to make incomplete features available >>> behind a command line flag to help facilitate testing. I understand >>> that the norm for WebKit is to only have compile time options for new >>> / incomplete features. In some cases, runtime settings are defined, >>> but these generally correspond to end user preferences or the needs of >>> specific embedders. >>> >>> At any rate, I just wanted to make sure that folks were aware that >>> some settings may only exist to help facilitate Chromium's goal of >>> shipping incomplete features, disabled by default. >>> >>> Alexey asked if there are any guidelines for when these settings may >>> be removed. I think the main thing is that the feature has to be >>> reasonably complete and enabled by default by embedders (e.g., >>> Chromium) that are compiling the feature. >>> >>> Regards, >>> -Darin >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
