Unresponsive script dialog usability problems

[Till Ulen]

Binary package hint: firefox

First, see attached screenshot. Here is a textual description of it.

The "Warning: Unresponsive script" dialog has two buttons: "Continue" and "Stop script". The Continue button's icon is a red X. The "Stop script" button's icon is a green Enter-like arrow. The text above the buttons reads: "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete."

Those who use slower computers are likely to see this dialog more often, because the performance of some scripts is not optimized by the developers who test only on faster machines.

Problems

1. When using a web application, stopping a script prematurely can lead to losing your work. If the web application implements its functionality using scripting and is not designed very carefully, terminating its script at an unfortunate point will destroy the user's data that it was processing. If the data hasn't been saved on the server, the user loses her work, because execution of the offending script cannot be resumed later from the same point.

The dialog doesn't explain that to the users, most of whom don't associate stopping a web page "script" with potentially losing their work. One way to fix that is to add a bold warning telling the user about the possibility of losing her work (if any) at that particular web page.

2. The red X icon for the Continue button is highly counter-intuitive. A red X means "close", "delete", "stop", almost the opposite of "continue". The green Enter-like arrow of the "Stop script" button, on the contrary, looks like "Continue", especially because of it color. Thus the user might easily click the wrong button and possibly lose her work in a web application.

To fix this, I suggest using the red X for the "Stop script" button and using some green icon for the Continue button. Enter-like arrow, however, is a poor choice for "Continue", because it is associated with submitting information and approval of some obvious action ("OK", "Yes"), and can be confusing when the task is to choose whether to stop or continue something.

I'm using Firefox 2.0.0.5+1-0ubuntu1 from 7.04 Feisty.

[John Vivirito (gnomefreak)]

Marking as incomplete for the time being until we get more testers to confirm this. tagging mt-needtester

[John Vivirito (gnomefreak)]

What theme and extensions are you using?

[John Vivirito (gnomefreak)]

Can you also give us step by step instructions on how to reproduce this?

[Alexander Sack (asac)]

On Tue, Jul 24, 2007 at 02:40:57PM -0000, Alexander Konovalenko wrote:
> Public bug reported:
>
> Binary package hint: firefox
>
> First, see attached screenshot. Here is a textual description of it.
>
> The "Warning: Unresponsive script" dialog has two buttons: "Continue"
> and "Stop script". The Continue button's icon is a red X. The "Stop
> script" button's icon is a green Enter-like arrow. The text above the
> buttons reads: "A script on this page may be busy, or it may have
> stopped responding. You can stop the script now, or you can continue to
> see if the script will complete."
>
> Those who use slower computers are likely to see this dialog more often,
> because the performance of some scripts is not optimized by the
> developers who test only on faster machines.

... this is a bit tricky, but in general I agree that it can be
confusing and should be improved.

 - Alexander

[Till Ulen (tillulen)]

Alexander, could you please elaborate on what exactly is tricky? I'm not sure I get what you mean.

[Alexander Sack (asac)]

On Tue, Jul 24, 2007 at 04:49:30PM -0000, Alexander Konovalenko wrote:
> Alexander, could you please elaborate on what exactly is tricky? I'm not
> sure I get what you mean.
>

There are two purposes:

 * The initial purpose was to abort scripts that are looping as they
 are primary considered malicious.

 * The second pupose is to continue scripts because your system is too
 slow for the javascript application.

For initial case, the idea is to guide the user to Stop the script
... so using green makes sense for Stop.

Now we have second valid use case ... its hard to decide.

 - Alexander

[Till Ulen (tillulen)]

> There are two purposes:
>
> * The initial purpose was to abort scripts that are looping as they
> are primary considered malicious.
>
> * The second pupose is to continue scripts because your system is too
> slow for the javascript application.
>
>For initial case, the idea is to guide the user to Stop the script
> ... so using green makes sense for Stop.
>
> Now we have second valid use case ... its hard to decide.

I see. I absolutely agree that it should be obvious for the user that faces a run-away script that she should click Stop. Leaving the Stop button the default one, which it is now, can help.

For me, stop is never supposed to be green, whether it is "bad" stop I'd like to avoid or a "good" stop I want to perform. Green means "go" in this context, and stop is just not go. Show me where is stop, and I'll then choose whether I want it or not, even if it's red.

The best way to properly resolve this is to conduct a tiny usability study. Testing with five non-programmers would be enough, as Jakob Nielsen has shown, if you don't make some beginner's mistakes in the process. Even showing them just colored paper prototypes is usually much better than no user testing at all.

If we can't think of some usable unambiguous icons for Stop and Continue, we are better off without either one. After all, the icons are supposed to make the text more obvious at a glance, not the opposite.

And please don't forget about information loss issue on slower machines. I'm not sure how likely it is to occur with real web applications, but if it does, it will be really frustrating for the users. Really.

[Alexander Sack (asac)]

On Wed, Jul 25, 2007 at 04:26:49PM -0000, Alexander Konovalenko wrote:
>
> I see. I absolutely agree that it should be obvious for the user that
> faces a run-away script that she should click Stop. Leaving the Stop
> button the default one, which it is now, can help.
>
> For me, stop is never supposed to be green, whether it is "bad" stop I'd
> like to avoid or a "good" stop I want to perform. Green means "go" in
> this context, and stop is just not go. Show me where is stop, and I'll
> then choose whether I want it or not, even if it's red.
>
> The best way to properly resolve this is to conduct a tiny usability
> study. Testing with five non-programmers would be enough, as Jakob
> Nielsen has shown, if you don't make some beginner's mistakes in the
> process. Even showing them just colored paper prototypes is usually much
> better than no user testing at all.
>
> If we can't think of some usable unambiguous icons for Stop and
> Continue, we are better off without either one. After all, the icons are
> supposed to make the text more obvious at a glance, not the opposite.
>
> And please don't forget about information loss issue on slower machines.
> I'm not sure how likely it is to occur with real web applications, but
> if it does, it will be really frustrating for the users. Really.
>

Thanks for your thoughts, but its more suitable to discuss this
upstream, as its a general feature that is not ubuntu specific. Read
http://forums.mozillazine.org/viewtopic.php?t=555691 for info on how
to lobby for a feature upstream.

Thanks for your contributions,

 - Alexander

[Till Ulen (tillulen)]

Attached is an HTML file that enters an infinite loop in JavaScript when loaded. Opening that file is an easy way to have Firefox show the "Warning: Unresponsive script" dialog and play with it.

Please DON'T OPEN THE ATTACHED FILE IF YOUR BROWSER CAN'T HANDLE RUN-AWAY JAVASCRIPT.

[Till Ulen (tillulen)]

Alexander, thanks for the link about lobbying features upstream.

I've got one problem with reporting this upstream: I don't know whether the controversial icons exist in the upstream version or they were added in Debian or Ubuntu.

If anyone can post a screenshot of the "Unresponsive script" dialog from a vanilla Firefox for Linux build from mozilla.com, I would be grateful. You can use the file from my previous message to produce that dialog.

  -- Alexander Konovalenko

[John Vivirito (gnomefreak)]

Using the link in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/127960/comments/10
I dont have icons with default human theme at all. Screenshot is attached.

[Till Ulen (tillulen)]

John Vivirito wrote:
> Using the link in
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/127960/comments/10
> I dont have icons with default human theme at all. Screenshot is attached.

John, I'm running Ubuntu 7.04 Feisty Fawn with latest security and recommend updates. Do you have the same?

I have the following package versions installed:

firefox 2.0.0.5+1-0ubuntu1
firefox-gnome-support 2.0.0.5+1-0ubuntu1
libgtk2.0-0 2.10.11-0ubuntu3

What are yours?

[John Vivirito (gnomefreak)]

thats odd. Im not sure if this is firefox causing those icons. I find it hard to believe that firefox 2.0.0.5feisty and firefox2.0.0.5gutsy show it differnetly. Let me see what i can find over the weekend and i will get with Alexander Sack and see what we come up with. The 2 packages last i looked were just about the same other than the depends they are built on IIRC.

[Till Ulen (tillulen)]

The test case was attached here in the comments. What is blocking further work is the need to check whether this occurs in the upstream version of Firefox for Linux.

[Alexander Sack (asac)]

please never go back to new ... this is still incomplete (as you already outlined)

[Matěj Cepl (mcepl)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3

Originally from the Red Hat Bugzilla:

In the "Unresponsive script" dialog, "continue" should be labelled as the "arrow" and "stop script" be the "x" (currently, "stop script" is labelled with arrow, and "continue" has nothing).

Reproducible: Always

Steps to Reproduce:
1. see above
2.
3.
Actual Results:
see the image attached to this bug

Expected Results:
Continue should be labelled with arrow, and Stop script with Cross or something.

[Matěj Cepl (mcepl)]

Created an attachment (id=305534)
FF2 screenshot of the dialog

[Sylvain Pasche (sylvain-pasche)]

Firefox 3 screenshot: see attachment 323426

[Sylvain Pasche (sylvain-pasche)]

*** Bug 436910 has been marked as a duplicate of this bug. ***

[Till Ulen (tillulen)]

I can reproduce this in Firefox 3.0.1 from Hardy (package version 3.0.1+build1+nobinonly-0ubuntu0.8.04.3) with the above test case.

[Alexander Sack (asac)]

firefox 2 wont see a fix for this.

[Alexander Sack (asac)]

this needs to be delt upstream. Please verify that this still exists in ffox 3, search bugzilla.mozilla.org for duplicates and if you dont find one open a new bug and let us know about the bug id.

[Hskupin (hskupin)]

*** Bug 463178 has been marked as a duplicate of this bug. ***

[Pedro Villavicencio (pedro)]

Any news about this? did somebody sent it upstream? may you please tell us the bug number there? thanks in advance.

[Matti-mversen (matti-mversen)]

*** Bug 491042 has been marked as a duplicate of this bug. ***

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu Bug:
https://bugs.launchpad.net/bugs/127960

Still a problem in Firefox 3.5 and 3.7 (trunk)

[Sylvain Pasche (sylvain-pasche)]

Created an attachment (id=395217)
patch

nsIPrompt assumes that the button at position 0 has an ok/yes icon and the one at position 1 cancel/no. That's only meaningful for Linux as other OSes don't show icons there.

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugzilla.mozilla.org/show_bug.cgi?id=419463

[Dao (dao)]

http://hg.mozilla.org/mozilla-central/rev/ba9cb47432a6

[Sylvain Pasche (sylvain-pasche)]

Verified fixed on trunk with build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091026 Minefield/3.7a1pre on Linux Ubuntu 9.04 32bit.

[Micah Gersten (micahg)]

@Alberto Urzúa
Please don't change the status without specifying why.

[Micah Gersten (micahg)]

Resurrecting this task as firefox is unversioned for 3.6 and up.

[Clegnitto (clegnitto)]

(From update of attachment 395217)
a=LegNeato for 1.9.2.5. Please ONLY land this on mozilla-1.9.2 default, as we
are still working on 1.9.2.4 on the relbranch

[Hendy Irawan (ceefour)]

Whoa! A three year old bug.. just for two button icons! :-)

[Sylvain Pasche (sylvain-pasche)]

If someone could land it on branch for me, that would be terrific.

[Mak77 (mak77)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5fa8c4f2c1dc

[Micah Gersten (micahg)]

firefox (3.6.7+build2+nobinonly-0ubuntu1) maverick; urgency=low

  * New upstream release v3.6.7build2 (FIREFOX_3_6_7_BUILD2)

  * Make it possible to disable patches on a per-release basis. This
    makes it easier to share packaging branches across releases, and makes
    it possible to disable the patches which make the Hardy daily builds fail
    - update debian/rules
    - add debian/disable-patches.sh
    - add debian/patches/series-disable-patches.8.04
  * Make the debian/usr.bin.firefox.apparmor.in target a dependency of
    pre-build rather than makebuilddir. Whilst this doesn't really change
    much, it is technically slightly more correct (makebuilddir is just for
    creating the build directory, whilst pre-build is for doing all the
    preparation work)
    - update debian/rules
  * Merge the debian/firefox.sh target in to the match-all target, this
    just de-clutters things a little
    - update debian/rules
  * Remove debian/stamp-autotools-files-moz in the clean target
    - update debian/rules
  * Drop the empty firefox-dev and firefox-*-dev transitional packages. We
    didn't install anything in to firefox-dev, and we can reintroduce it in
    the future if anything in the archive depends on the browser specific
    interfaces
    - update debian/control
    - remove debian/firefox-dev.install
    - remove debian/firefox-dev.links
  * Fix some Lintian warnings
    - add debian/README.source
    - update debian/control
  * Make debian/migrator/ffox-beta-profile-migration-dialog a dependency of
    post-patches rather than pre-build. This avoids the need for having to
    build the profile migrator when unpacking the source tarball
    - update debian/rules
 -- Chris Coulson <email address hidden> Thu, 15 Jul 2010 20:27:51 +0100

[Micah Gersten (micahg)]

Released to Hardy/Jaunty

[Micah Gersten (micahg)]

Released as 3.6.7 to Karmic