On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson <atwil...@google.com> wrote:
> > On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig <sam.wei...@gmail.com> wrote: > >> >> >> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <atwil...@google.com> wrote: >> >> 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. >>> >> >> Sorry, I seemed to have missed that thread. I did however file a bug as >> soon as the first runtime switch went in. >> >> >>> 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. >>> >> >> I obviously disagree with Maciej on this. I think it is bad to break >> developers expectations for feature detection. >> >> > OK, it's good to get consensus, even if it comes after I already thought we > had achieved it :) > > From a purist's perspective, I see where you'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've discussed > removing these feature flags (and the ability to disable the features at > runtime) once the features become stable - I don't know if that's a good > idea or not, but that might impact this discussion as well. > That is not true, they are also available in nightly builds at http://nightly.webkit.org/. > > >> >>> 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 >>> >> >> I don't mean to single out SharedWorkers or WebSockets, but I don't see >> any others using the same technique (barring window.Audio, which I don'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. >> > > Take a look at DOMWindow.cpp - there's quite a bit of code that does > something like "look at settings to see if feature is enabled, return null > if not" (DOMWindow::openDatabase(), for an example). > > 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. -Sam
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev