> Wait, what? The semantics of the web demands that runaway JS block any other
> even turns, or page layout/rendering from proceeding. Multi-process browsers
> can prevent cross-origin pages from interfering with each other, and Servo
> can do speculative layout to reward well-behaved pages, but badly-behaved
> pages unavoidably destroy the UX. Maybe I'm unimaginative but the only
> alternative to the slow-script dialog I can see is to allow a page to
> completely destroy itself unrecoverably.
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.
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.
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.
By the way this kind of solution is totally applicable to
setTimeout/setInterval loops that for now aren't covered by the script dialog,
or a script that overuse your GPU with offscreen WebGL.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
