window.applicationCache does something different when the runtime switch is disabled which definitely breaks feature detection. It returns a non-null, but non-functioning object. At some point I had changed it to return 'null' when disabled, but later reverted that change and went back to the non-null but not-working state of affairs after discussing things with ap. On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson <atwil...@google.com> wrote:
> Ooops, meant to reply to all. > > On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson <atwil...@google.com> wrote: > >> >> >> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig <sam.wei...@gmail.com> wrote: >> >>> >>> >>> That is not true, they are also available in nightly builds at >>> http://nightly.webkit.org/. >>> >> >> I'm not sure what you mean, exactly - the nightly webkit builds all have >> SharedWorkers turned on, with no way to turn them off short of editing the >> source code and recompiling (since the only existing implementation of >> SharedWorkerRepository.isAvailable() returns true). I suspect I'm missing >> something obvious, though - can you elaborate? >> >> My expectation was that only when I write the Chromium implementation of >> SharedWorkerRepository will isAvailable() ever return false - so this only >> affects Chromium deployments. >> >> >>> >>> >>>> >>>> >>>>> >>>>>> 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. >>> >> >> Why doesn't it affect feature detection? Someone can do "if localStorage >> in window", yet have their code fail when window.localStorage is null? >> >> >>> >>> -Sam >>> >> >> > > _______________________________________________ > 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