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.<br>
<div class="gmail_quote"><br></div><div class="gmail_quote">-Sam</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Oct 5, 2009 at 5:54 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<div>
<br></div><div>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?<div>
<div><br></div><div>-atw<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, two weeks ago I sent an email on this thread stating exactly what I was planning to do, To whit:<div><br></div><div>>>></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
<div>
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.</div>
<div><<<</div><div><br></div></div><div>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):</div>
<div><br></div><div>>>></div><div>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 <b>probably too complicated to be worth it</b>. 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.</div>
<div><<<</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-atw</div><div><br></div></span><br><div class="gmail_quote"><div>On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig <span dir="ltr"><<a href="mailto:sam.weinig@gmail.com" target="_blank">sam.weinig@gmail.com</a>></span> wrote:<br>
</div><div><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Folks,</div><div><br></div>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 <a href="https://bugs.webkit.org/show_bug.cgi?id=29896" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=29896</a> 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.<div>
<br></div><div>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.</div><div><br></div><div><font color="#888888">-Sam<br>
<br></font><div class="gmail_quote"><div>
On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>></span> wrote:<br></div><div><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As is described in <a href="https://bugs.webkit.org/show_bug.cgi?id=28941" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=28941</a>, for<br>
the Chromium project, we like to make incomplete features available<br>
behind a command line flag to help facilitate testing. I understand<br>
that the norm for WebKit is to only have compile time options for new<br>
/ incomplete features. In some cases, runtime settings are defined,<br>
but these generally correspond to end user preferences or the needs of<br>
specific embedders.<br>
<br>
At any rate, I just wanted to make sure that folks were aware that<br>
some settings may only exist to help facilitate Chromium's goal of<br>
shipping incomplete features, disabled by default.<br>
<br>
Alexey asked if there are any guidelines for when these settings may<br>
be removed. I think the main thing is that the feature has to be<br>
reasonably complete and enabled by default by embedders (e.g.,<br>
Chromium) that are compiling the feature.<br>
<br>
Regards,<br>
-Darin<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div></div></div><br></div>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br>