On Mon, Sep 21, 2009 at 2:55 PM, Jeremy Orlow <[email protected]> wrote:
> On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman <[email protected]> wrote: > >> It is really useful to have early code compiling and running as much >> as possible on all platforms right from the beginning. This catches a >> lot of issues early in the development cycle and prevents scary >> monolithic integration phases. >> > > Even in beta/stable releases? If people want to test bleeding edge > features, I'd argue they should be on the dev channel. > > >> Could we also fix this problem by doing something in the >> bindings-generation phase to just not have these features' >> constructors created? >> > > Possibly. It's still possible that it'd have a > non-trivial maintenance and/or performance cost though. I believe Drew is > going to explore further, but for now (and Chrome 3) we should assume such > an option is not available. > > On Mon, Sep 21, 2009 at 2:52 PM, Mike Belshe <[email protected]> wrote: > >> On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow <[email protected]>wrote: >> >>> I think we need to re-consider our practice of shipping beta/stable >>> browsers with experimental features hidden behind flags--at least when they >>> have any side-effects in JavaScript. An example of where this has bitten us >>> is http://code.google.com/p/chromium/issues/detail?id=22181 >>> >>> Although part of the problem is the way they coded things (since both >>> SessionStorage and LocalStorage use the Storage interface, >>> its existence doesn't imply SessionStorage is necessarily available), this >>> bug has pointed out a couple problems. 1) constructors are visible to >>> javascript even when the feature is totally disabled. >>> >> >> If it's behind a flag, it shouldn't have been exposed, right? >> > > As I explained, this is not true. > Oops...misread your statement. Ignore that comment....or assume I said "As I explained, this is currently not true." > On the surface, it sounds like this code was only partially hidden behind >> the flag? >> > > Yes. > > >> I think it would be a good idea to have a unit test which enumerates all >> symbols that we're exposing into JS. This should be a controlled list. >> > This probably makes sense. If we had this unit test, would it have caught this exposure? >> > > Yes. The point is that (pending Drew's investigation) it's probably not > practical to completely hide all side effects of run time flags that turn on > JavaScript features in WebKit. > > J > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
