487898 - Per-site dom.max_script_run_time ("don't ask again about unresponsive scripts")

Status: NEW

(Core :: JavaScript Engine, enhancement, P5)

Description

[Matthew Cline]

There's one particular site where I always answer "continue" to "A script on this page may be busy", but on all other sites I answer "stop".  It would be nice if I could set dom.max_script_run_time to infinity (0) for just that one site so that I don't have to frequently get the "Unresponsive script" popup, and keep it at 10 for all the rest of the Internet.  Or at least a hook that an addon could use to implement this.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Not exactly the same but the NoScript extension could help.
https://addons.mozilla.org/en-US/firefox/addon/722

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm thinking of fixing this using the content pref service. The one problem I foresee is that the API for that is async. However, it does have a cache that can be accessed synchronously. Blake, what do you think of the idea of caching at startup all the websites where the slow script dialog is disabled? I can't imagine a typical user would have many of them. If we do that, then I think it should be pretty easy to fix this bug.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Bill McCloskey (:billm) from comment #2)
> I'm thinking of fixing this using the content pref service. The one problem
> I foresee is that the API for that is async. However, it does have a cache
> that can be accessed synchronously. Blake, what do you think of the idea of
> caching at startup all the websites where the slow script dialog is
> disabled? I can't imagine a typical user would have many of them. If we do
> that, then I think it should be pretty easy to fix this bug.

My initial patch for the content pref service didn't include the cached versions of the functions (see bug 1027898, comment 12). It'd make sense to me to add it. Drew, what do you think?

If not, it wouldn't be too hard to do something one-off for this case (just send down the list through ipdl).

Comment 4

[Drew Willcoxon :adw]

This does sound like a job for content prefs, and I'm definitely not opposed to adding the cached functions to the e10s version of the service if we need them.

I'm a little concerned about opening the contents prefs DB and reading from it on startup just for these slow script dialog prefs.  It'd be off the main thread but it's still I/O on startup that is not necessary in, I'd say, the vast majority of cases.  In terms of performance, I don't think it really matters how many of those prefs there are.  It's the opening and searching the DB at all that matters.  Now, maybe it's the case that in practice the content prefs DB is usually opened and read from on startup anyway, when you have a restored session, I don't know.  If that's true then it's probably not a big deal.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

We don't necessarily have to cache all of the values on startup. It would probably be enough to grab the setting at the beginning of pageload (we'd just make sure to have the value cached in the child before the first page JS runs).

Comment 6

[Nicolas B. Pierron [:nbp]]

Now that we have fission, with per-origin processes, I guess this might be easier to implement.