The assert is invalid when lazily compiling extensions code. We are really asserting the wrong thing here. I will propagate enough information to the parser to assert the right thing.
-- Mads On Fri, Aug 28, 2009 at 11:50 AM, Mads Sig Ager<a...@chromium.org> wrote: > John, > > I'll look into the assertion failure. I'm not sure why you are > hitting that one - that assert is exactly setup that way to allow eval > in extensions but not in our own native function code. > > That said, I think this is a pretty nasty hack and I think we should > avoid putting it in if we can. There are so many ways users can make > stuff in onunload handlers take a long time. Lying about the time to > avoid one case seems like a bad idea. I'm not sure I agree that it is > the browser's problem that a user decides to perform long-running > operations in onunload. If we believe that the browser should > disallow that, maybe we should explicitly set a timout after which > javascript execution in onunload will be forcefully terminated? That > will probably have other issues though. > > Cheers, -- Mads > > On Fri, Aug 28, 2009 at 5:06 AM, John Abd-El-Malek<j...@google.com> wrote: >> Hi, >> In investigating a bug where tabs take a long time to close, I tracked the >> issue to sites simulating sleep in their unload handlers. They do this by >> looping until Date.getTime changes by enough ms. I'm now prototyping >> disabling these sleeps by skewing the time after a large number of getTime >> calls in an unload handler. Here's the changelist where I implemented it >> using a V8 extension: http://codereview.chromium.org/178010/show. This is >> the short term fix, while we implement better methods for having requests >> outlive a page, so that the ad networks can do whatever they need to do >> without blocking the user. >> The problem I'm running into is that in overriding the Date constructor I >> needed to use eval. This was the only way I could find where I can override >> the constructor with no arguments and have that go through my logic of >> skewing the time, while maintaining existing behavior for the other >> constructors. The problem is I run into this assert in >> parser.cc:"ASSERT(extension_ != NULL || !Bootstrapper::IsActive());", which >> is triggered by my use of eval for an internal script. >> I wanted to see what you guys think of this. Is there another way that >> you'd prefer that this be implemented, i.e. have something in the V8 API >> which allows a user to filter getTime calls? Or if this approach is ok, can >> we take out that assert, or have a way for an extension to not trigger it? >> >> Thanks, >> John >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
