<br><br><div class="gmail_quote">On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com">atwilson@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote"><div class="im">On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig <span dir="ltr">&lt;<a href="mailto:sam.weinig@gmail.com" target="_blank">sam.weinig@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br><br><div class="gmail_quote">On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:</div></div><div class="gmail_quote">

<div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>I&#39;m surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. </div>


</span></div></blockquote><div><br></div></div><div>Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>That said, I agree that in an ideal world, we&#39;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&#39;t a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway.</div>


</span></div></blockquote><div><br></div></div><div>I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection.</div><div><div><br></div></div></div></blockquote>
<div><br></div></div><div>OK, it&#39;s good to get consensus, even if it comes after I already thought we had achieved it :)</div><div><br></div><div>>From a purist&#39;s perspective, I see where you&#39;re coming from. Pragmatically, though, these runtime flags are only available on the Chrome dev channel (and go away before the features are ever shipped to the beta/stable channels) so the compatibility issues are somewhat moot. We&#39;ve discussed removing these feature flags (and the ability to disable the features at runtime) once the features become stable - I don&#39;t know if that&#39;s a good idea or not, but that might impact this discussion as well.</div>
</div></blockquote><div><br></div><div>That is not true, they are also available in nightly builds at <a href="http://nightly.webkit.org/">http://nightly.webkit.org/</a>.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">
<div><br></div><div>Regardless, I don&#39;t think we should rush out to roll all of those features out of the tree, and I certainly don&#39;t think we should be singling out SharedWorkers or WebSockets</div></span></div>


</blockquote><div><br></div></div><div>I don&#39;t mean to single out SharedWorkers or WebSockets, but I don&#39;t see any others using the same technique (barring window.Audio, which I don&#39;t think is the same thing, but should non-the less be fixed).  But, as we have many developers using the nightlies, I think this should be handled with some speed.</div>

</div></blockquote><div><br></div></div><div>Take a look at DOMWindow.cpp - there&#39;s quite a bit of code that does something like &quot;look at settings to see if feature is enabled, return null if not&quot; (DOMWindow::openDatabase(), for an example).</div>

<div><br></div></div></blockquote><div><br></div><div>This is indeed unfortunate, but also is a step removed, since it does not really effect feature detection, it is also not a shipping configuration.</div><div><br></div>
<div>-Sam</div></div>