756588 - testcase: non-responsive worker

Status: RESOLVED WONTFIX

(Firefox Graveyard :: SocialAPI, defect)

Description

[Shane Caraveo (:mixedpuppy)]

need to test a non-responsive worker and see what happens, make sure ui works correctly, etc.

Comment 1

[Mark Hammond (PTO; back Oct-3) [:markh] [:mhammond]]

It depends what you mean by "non responsive" - if it simply means it doesn't respond to messages, I think it would work fine.  However, a "hanging" provider (eg, one in an infinite loop) is a more likely problematic scenario - the best we could hope for there is that the "unresponsive script" dialog would offer to kill it for us.

Comment 2

[Shane Caraveo (:mixedpuppy)]

This bug is about making sure the "unresponsive script" UI works.

Comment 3

[Shane Caraveo (:mixedpuppy)]

some background.  testing for this is looking to be non-trivial, but looking for more feedback.


mixedpuppy: dolske: I'm wondering how to test for a non-responsive sandbox, or at least how to test that the non-responsive dialog appears
dolske: mixedpuppy: not sure if there's a good solution.
mixedpuppy:   ok
[1:04pm] dolske: might be interesting to play with a Worker, ping-ponging to the main thread and have it measure latency.
[1:04pm] dolske: what are you doing that risks a slow-script dialog?
[1:05pm] mixedpuppy: we have a background sandbox running a script from a remote site, want to be sure that if it becomes unresponsive that it is handled well
[1:06pm] mixedpuppy: my hope is that the non responsive script dialog would just kick in, but I wanted to test for it somehow
dolske: hmm
[1:06pm] dolske: y'know...
[1:07pm] dolske: for a sandbox, we ideally probably don't even want a slow-script dialog. because there's no page (tab) associated with it.
[1:07pm] dolske: so exposing it to the user isn't all that helpful.
[1:07pm] dolske: but
[1:07pm] dolske: it would be interesting to have a way to create a sandbox and specify an (option) max-runtime and hookup a onSlowScript callback.
[1:07pm] bnicholson left the chat room. (Ping timeout)
[1:08pm] mixedpuppy: that would be helpful for us
[1:08pm] dolske: bet the JS guys could whip that up quick enough.
[1:08pm] • dolske forgets where that code is exactly

[1:10pm] gavin: the same mechanism the slow script dialog uses (DOMOperationCallback) should be easily adaptable to that, I think
[1:11pm] dolske: ah http://mxr.mozilla.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#652
[1:11pm] dolske: right, not sure if there's any machinery in place to change that arbitrarily or by JS
[1:14pm] dolske: file a bug and CC jst/bholley?
[1:15pm] mixedpuppy: dolske: sure, ok if I copy some of this convo to it?
[1:15pm] dolske: sure!
[1:15pm] mixedpuppy: thanks!
[1:15pm] dolske: this is probably a core::xpconnect thing

Comment 4

[Adam Muntner [:adamm] (use NEEDINFO)]

Any movement on this one?

I am curious to see if anyone has done any testing to see how it could affect the overall browser's performance - that my biggest concern right now.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Bug 771977's fix causes us to terminate the worker script after the default script timeout, which is 10 seconds. I think that meets the minimal bar for shipping, though we could still improve the experience (track when it happens, explicitly disable a worker that does this often, etc.).

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

I don't think this is a blocker anymore.

Comment 7

[Shane Caraveo (:mixedpuppy)]

closing in preference to bug 898706