I don't think I wrote the Audio code, (I think I probably just moved it), but I also don't believe it is intended as a general purpose runtime switch (but rather fallback when there are no installed codecs). It is also not something people are going to ship as far as I can tell, and is therefore a much smaller compatibility risk.
-Sam On Mon, Oct 5, 2009 at 5:54 PM, Drew Wilson <atwil...@google.com> wrote: > 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 <atwil...@google.com> 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 <sam.wei...@gmail.com> 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 <da...@chromium.org>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 >>>> webkit-dev@lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev