On Aug 12, 2013, at 5:40 PM, François REMY <[email protected]> wrote:
> I don't think of you as unimaginative, but I think there are other options. :) > Sure, there must be a way to "kill" a script that's burning your CPU but it > doesn't have to be a dialog. That's fine, I guess I didn't really mean dialog box was the only UI, just that killing the JS entirely is the only reasonable semantics I can imagine. > Firstly, there's nothing really preventing a browser to perform a layout if > it actually pauses the script, even if it may be hard to pause a thread while > keeping all its pointer safe in an environment that's changed by another > thread. But this is not impossible. Not impossible to implement, but very bad. It would create new preemption semantics to shared state in JS, which is moooost of the time trying very hard to be strictly based on cooperative concurrency. Not only would injecting this preemption be a new potential source of very subtle bugs, it could be a security problem (run some slow script to force a new layout and use that as a bogus communication channel). > Secondly, when a website becomes resource-intensive, you can display a > "toolbar" saying 'This website looks to overuse your computer.' with a (stop > the script) button that doesn't interrupt your experience (you can switch tab > if you want, which will in return cause the tab to get way less system > resources since he's in the background) or continue to use the website if it > turns out it's just slow but not stuck in an infinite loop. Sure-- again, playing with the UI isn't really what I meant. It's that semantically I see no alternative to a slow script but killing JS. Dave _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
