579576 - Thunderbird cannot stop loading messages using the customizable "stop" toolbar button (ESC keyboard shortcut now used to clear/hide quickfilter bar, no longer used for cmd_stop)

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[WD]

With Thunderbird 3.0, a message (email, RSS entry, etc.) can be stopped from loading by pressing Escape.  With Thunderbird 3.1, pressing escape now makes the search bar disappear (if it was present) and additional presses do nothing with respect to the loading message.

Steps to reproduce:
1. Select a large message or a message on a slow server
2. As the message is loading, press Escape

Actual results:
The message doesn't stop loading

Expected results:
The message should stop loading when escape is pressed.  If the search bar is present, perhaps the first press could cause it to disappear and then the subsequent press would cause the message to stop loading.

This is a regression from Thunderbird 3.0, probably introduced with the new search bar.

Comment 1

[Ludovic Hirlimann [:Usul]]

Have you tried safe mode? (see https://support.mozillamessaging.com/en-US/kb/Safe+Mode for more information)

Anything in Tools -> Error console when you press ESC.

Is this over imap ?

Comment 2

[Ludovic Hirlimann [:Usul]]

WD can you try to find the regression window using http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ as instructions ?

Comment 3

[WD]

This happens for any connection, I believe.  I'm seeing it with RSS in particular, though.

The regression happened between build 2010-04-21-03-comm-1.9.2 and 2010-04-22-03-comm-1.9.2.

The former can stop a message from loading by pressing escape.  The latter build cannot.

Comment 4

[WD]

This bug appears to be caused by the fix for bug 525716
It is more of a problem because bug 239616 is still unfixed.

Comment 5

[MacedonKE]

The "Stop" button, in Thunderbird 2.0.0.24 (Windows 2000, SP4), successfully interrupts or stops downloading of messages from POP3 mail servers.  

However, in Thunderbird 3.1.6 (Windows 2000, SP4) the "Stop" button fails to interrupt or stop downloading messages from POP3 mail servers.

Comment 7

[Wayne Mery (:wsmwk)]

duping doesn't feel correct to me.  
This bug is a regression. bug 311948 is not a regression.  
This bug is about escape key.  bug 311948 is not.

The stop button would be a workaround, but not a fix.
Wontfix seems like the inevitable conclusion here.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

I am going to fix this by creating a new command that the quick filter bar will use for the purposes it is currently misusing cmd_stop for.  I am keeping the escape key for the quick filter bar and cmd_stop will be stuck being triggered by its customizable toolbar button and the menu item I can't seem to figure out how to make show up (at least, not without reading the source.)

(It is my understanding that we intentionally allocated the escape key to the quick filter bar as a UX decision.  It was, however, my error in letting the  prototype's hack for accomplishing this regress the stop button.)

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

I've pushed a fix to try:
http://hg.mozilla.org/try-comm-central/rev/13a964265971

The change also adds explicit calls to explicitly update cmd_stop when we start and stop the meteors, since that is what cmd_stop's enablement is actually gated on.  Since we only start the meteor spinning after a 0.5 sec timeout (presumably to reduce flicker and UI load for what should be fast things), this means it may not be on all that much in cases where things are running fast.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Attachment: v1 patch as pushed to try server with one minor comment change

My try-server push was green on windows and both macs, linux mozmills had some oranges that look known and unrelated.

Builds are here if people could please given them a spin:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tryserver-builds/[e-mail]-13a964265971/

While most of the patch is straightforward, my change to update the toolbar button status based on the meteors probably merits some consideration.

The patch does not add any new tests since:

- The desired quick filter bar escape key behavior is already well-covered by mail/test/mozmill/quick-filter-bar/test-keyboard-interface.js

- Testing the stop mechanism seems disproportionately hard to do given the simplicity of no longer intercepting "cmd_stop" (especially in a non-orange-prone fashion).  Specifically, the stop button is only relevant when asynchronous native operations are in progress.  Since those operations are dependent on network traffic, we could likely cause the fake server to defer responding to requests, but I think it would still take a good deal of time which is not merited in this case.

Comment 11

[WD]

(In reply to comment #10)
> My try-server push was green on windows and both macs, linux mozmills had some
> oranges that look known and unrelated.

I tested the 64-bit Mac build and the Stop button does now work properly.

Comment 12

[David :Bienvenu]

Comment on attachment 494764 [details] [diff] [review]
v1 patch as pushed to try server with one minor comment change

The stop button is working again with the patch. I'm a little unclear on why escape couldn't stop the current message load if there's no quick search going on - would that be hard to do?

Comment 13

[Wayne Mery (:wsmwk)]

> I'm a little unclear on why
> escape couldn't stop the current message load if there's no quick search going
> on - would that be hard to do?

whether or not it is:
a) it'd be overloading escape much like ctrl+F does to Find - which has proven to be not good
b) it's undiscoverable - although probably welcome to people who already know about it, especially if there isn't another keyboard equivalent

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

What Wayne said.  If we imagine a state machine model for the two thangs going on where hitting escape makes us go left a state, we have:

Stop State Machine:
  |Not doing anything stoppable| <--escape-- |Doing something stoppable|

Quick filter state stack machine:
  |hidden| <--escape-- |no filters active| <--escape-- |all but last active|
    <--escape-- |all and last active|


Since these are independent state machines, it would be unclear which machine an escape key should apply to.  It seems likely to be really confusing and quite frustrating especially since many of the stoppable actions are not directly triggered by the user.

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

pushed to trunk:
http://hg.mozilla.org/comm-central/rev/82e3af81389e

Requesting permission to land on 3.1 after requisite baking.

Comment 16

[Miles]

Using WinXP, TB  3.1.6 there is no "stop" button in any of the bars.  Also not listed in Customize.  Is this perhaps a feature in a different version?  Also went to the site listed in comment 10 where there are multitudes of files listed under tryserver win32 and have no idea which one(s) to use and if they are in fact designed to work with 3.1.6 or a later version, and if used in 3.1.6 would they complicate or change anything else (I'm not in a test program)?

Comment 17

[[e-mail]]

(In reply to comment #16)
> Using WinXP, TB  3.1.6 there is no "stop" button in any of the bars.  ...

Miles, your finding is contrary to mine.  I find that, using Win XP Professional, SP 3, the "Stop" button is available in both the main toolbar and in the new toolbar in the individual mail headers of Thunderbird 3.1.6.  However, the button does not function; it appears to be in the "active" state at all times but does not seem to have any effect.

(I also find that the "Stop" button in the main window does function properly, stopping the current transfer, in Thunderbird, version 2.0.0.24, using Windows XP Professional, SP3.  Stopping the downloading of mail from POP3 server is a function that I require with sufficient frequency that I have been forced to stop using TB3.x and have reinstalled TB2.0.0.24 on one of my computers.)

Comment 18

[[e-mail]]

Will this "fix" or stop button update be made available as an "Add-on" or will it be incorporated in the next version of TB3.x?

Comment 19

[Andrew Sutherland [:asuth] (he/him)]

(Updating subject to reflect the actual fix implemented.  Making the escape button trigger the stop mechanism is WONTFIX.)

Comment 20

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #18)
> Will this "fix" or stop button update be made available as an "Add-on" or will
> it be incorporated in the next version of TB3.x?

The fix is available in Thunderbird 3.3 nightlies and will ship in the final release of Thunderbird 3.3.  It is my hope that we will also land it on the 3.1.x branch once we are confident there are no surprises that would cause regressions on the 3.1.x branch.

Comment 21

[Miles]

Adding to Comment 16, I found the stop button.  For some stupid reason I must have been looking at Firefox' toolbars, not TB's.

Comment 22

[Andrew Sutherland [:asuth] (he/him)]

important note! This patch regressed the subscribe dialog, and bienvenu provided a fix for that on bug 579576.  If this patch is landed on 3.1, it *must* be landed with that fix as well (or be restructured.)

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #22)
> important note! This patch regressed the subscribe dialog, and bienvenu
> provided a fix for that on bug 579576.  If this patch is landed on 3.1, it
> *must* be landed with that fix as well (or be restructured.)

Some really impressive cut and paste work by myself there.  I intended to reference bug 618528.

Comment 24

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 494764 [details] [diff] [review]
v1 patch as pushed to try server with one minor comment change

this is a bit late to the party but here's my ui-r+ anyway.

Comment 26

[Thomas D. (:thomas8)]

I think we should start documenting changes that affect keyboard shortcuts in the summary of the respective bugs. It's pretty hard to find culprits and keep "Keyboard Shortcuts" (1) up to date without such hints, years after the deed was done.

Furthermore, use new tracker bugs:
- tb-keyboard-tracker bug 713979 for any bugs that (might) involve keyboard shortcuts
- tbkbd-doc-tracker bug 714031 for bugs that actually require changes in the documentation of keyboard shortcuts

So I'm about to remove outdated info from main keyboard shortcuts documentation (1):

Stop: [ESC]       (sic! not that this has ever been intelligible, but anyway...)

Another rumor eradicated.

Comment 27

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #26)
> So I'm about to remove outdated info from main keyboard shortcuts documentation

(1) https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts

Comment 28

[Mark Banner (:standard8)]

(In reply to Thomas D. from comment #26)
> I think we should start documenting changes that affect keyboard shortcuts
> in the summary of the respective bugs.

I disagree that it is the right place to do that, lets talk about this on tb-planning or somewhere.

Comment 29

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #26)
> So I'm about to remove outdated info from main keyboard shortcuts
> documentation (1):

Keyboard Shortcuts documentation fixed per Bug 714041 Comment 2 (ThomasD):

> I fixed this in major revision 5658 (1), as documented in bug 721666.
> - removed "Stop: [ESC]"
> - added:
> |Clear current Quick Filter; hide Quick Filter Bar||{key Esc} (as often as
> needed)

(1) https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts/revision/5658