Open Bug 1468925 Opened 6 years ago Updated 4 months ago

Spacebar doesn't always advance to next unread message

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mozillabugz, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

eml mwssage the will always repro for me
42.50 KB, message/rfc822
Details 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605171542

Steps to reproduce:

I did a fresh install of TB60b7 rather than upgrade my decade old 52.8, I am used to being able to have spacebar both scroll within long messages and advance to the next unread message.

This happens with messages in newsgroups, I probably haven't received sufficient emails yet to know if it also happens with them too.


Actual results:

The spacebar can now get "stuck" either in the middle of a thread, or at the end of a thread, and won't advance to the next message.  The 'n' key always manages to advance once the spacebar has got stuck.


Expected results:

The spacebar should always advance to next unread message.
Does it also happen in safe mode?
 https://support.mozilla.org/en-US/kb/safe-mode-thunderbird
Flags: needinfo?(mozillabugz)
(In reply to Wayne Mery (:wsmwk) from comment #1)

> Does it also happen in safe mode?

Yes it does.
Flags: needinfo?(mozillabugz)
Joe, do you also see this with beta?
Component: Untriaged → Folder and Message Lists
Flags: needinfo?(jsabash)
To check if it was confined to newsgroups, I marked a bunch of old emails unread, and then tried to scroll through them to with just the spacebar.

Not many of my emails conversations are long threads, but I found it would get "stuck" on some single email messages, so I'd say it affects mail as well as newsgroups and is likely related to the individual messages rather than any thread they might happen to be in.
(In reply to Andy Burns from comment #4)

> I found it would get "stuck" on some single email messages

It seems reproducible ... if I re-mark those messages as unread and try to advance through them again, 
it always seems to get stuck on the same ones again, I probably haven't repeated that enough times to be *absolutely* sure it's always the same ones.

I've still not noticed anything in common between those it affects e.g. it's nothing obvious such as html vs plain text.
(In reply to Andy Burns from comment #5)

> I probably haven't
> repeated that enough times to be *absolutely* sure it's always the same ones.

After noting down a couple of dozen subject/sender/times, I can say I'm sure the same messages (when marked unread) will repeatedly cause it to get stuck.
Yep. Happens reliably in TB 60.0B7 Function works as expected in 52.8.0 I wll see if I can narrow the regression range later on
Flags: needinfo?(jsabash)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Aceman this is a minor bug, but a real one. Can you take a look  Workaround is to use the n key
Are there exact STR, then Alice White can find the regression easily (or at least it seems easy to me since it's always very fast).
Hmm, I can't reproduce it. Space seems to scroll through a message, once at the end it advances to the next unread message, scrolls, advances, etc. That's in a non-threaded view.
For me it generally finds a message to get stuck on within ten messages or so, if you have trouble finding one among your emails, I can perhaps suggest a set of usenet messages on a specific server/group that get stuck for me?
Comment on attachment 8986306 [details]
eml mwssage the will always repro for me

I downloaded the .eml file, opened it with TB and did a "Copy to>" my own inbox, then marked it plus a few messages either side of it as unread, and paged through them with the space bar, for me that message did *not* cause TB to get stuck.
I'm now seeing this bug out of beta in the 60.3.1 (32 bit) production release. I haven't seen a pattern as to which newsgroup posts fail to page with the spacebar. (I haven't seen this with emails but I don't normally page through consecutive emails with the spacebar.)

Same here, for some weeks now TB does fail on the space shortcut sometimes. I suppose it's from 60 on.

Here it's 60.5.0 on MacOS and e.g. Enigmail added

Still the same in 60.9.0 - you can't go to the next unread message with the spacebar any more.

Same thing on 70.0b3 (64-bit) for me (macOS 10.14.6). Seems very random to me.

https://mozilla.github.io/mozregression/ can be used to find a regression range. But it helps to have a reproducible problem.

Keywords: regression, regressionwindow-wanted

(In reply to Wayne Mery (:wsmwk) from comment #18)

https://mozilla.github.io/mozregression/ can be used to find a regression range. But it helps to have a reproducible problem.

Possible to find the regression range?

Flags: needinfo?(traut)
Flags: needinfo?(spam+bugzilla.mozilla.org)
Flags: needinfo?(mozillabugz)

I can't do much about that regression range. For me it started with version 60, ongoing up to my current 78.13.0.

Flags: needinfo?(traut)

Using the mozregression.exe:

  • comm-central build from 2017-03-17 is good
  • comm-central build from 2017-03-18 is no good.
    Unfortunately it stopped at this point with the following log record attached below. Apologies for the size of the insert - it showed as 4 lines in the log window, without any of the DEBUG messages. I have left them included, in case they are useful for understanding the next steps.

If I can do more, please don't hesitate to ask!

------------------------------------------8<-----------------------------------------------------------------
2022-07-01T17:58:03.078000: INFO : Narrowed nightly regression window from [2017-03-16, 2017-03-18] (2 days) to [2017-03-17, 2017-03-18] (1 days) (~0 steps left)
2022-07-01T17:58:03.086000: DEBUG : taskcluster.client: credentials key scrubbed from logging output
2022-07-01T17:58:03.087000: DEBUG : taskcluster.client: {'rootUrl': 'https://firefox-ci-tc.services.mozilla.com', 'maxRetries': 5, 'signedUrlExpiration': 900}
2022-07-01T17:58:03.087000: DEBUG : taskcluster.client: credentials key scrubbed from logging output
2022-07-01T17:58:03.087000: DEBUG : taskcluster.client: {'rootUrl': 'https://firefox-ci-tc.services.mozilla.com', 'maxRetries': 5, 'signedUrlExpiration': 900}
2022-07-01T17:58:03.087000: DEBUG : Using url: https://hg.mozilla.org/comm-central/json-pushes?changeset=424efa8d9bdaf3649a0aae4c613b1bd1cc40d078
2022-07-01T17:58:03.087000: DEBUG : redo: attempt 1/3
2022-07-01T17:58:03.087000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/comm-central/json-pushes?changeset=424efa8d9bdaf3649a0aae4c613b1bd1cc40d078',), kwargs: {}, attempt #1
2022-07-01T17:58:03.088000: DEBUG : urllib3.connectionpool: Starting new HTTPS connection (1): hg.mozilla.org:443
2022-07-01T17:58:03.779000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /comm-central/json-pushes?changeset=424efa8d9bdaf3649a0aae4c613b1bd1cc40d078 HTTP/1.1" 200 None
2022-07-01T17:58:03.809000: DEBUG : Using url: https://hg.mozilla.org/comm-central/json-pushes?fromchange=424efa8d9bdaf3649a0aae4c613b1bd1cc40d078&tochange=5d39d63d0bf223541c5515ab2691736f5a638ded
2022-07-01T17:58:03.810000: DEBUG : redo: attempt 1/3
2022-07-01T17:58:03.810000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/comm-central/json-pushes?fromchange=424efa8d9bdaf3649a0aae4c613b1bd1cc40d078&tochange=5d39d63d0bf223541c5515ab2691736f5a638ded',), kwargs: {}, attempt #1
2022-07-01T17:58:03.995000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /comm-central/json-pushes?fromchange=424efa8d9bdaf3649a0aae4c613b1bd1cc40d078&tochange=5d39d63d0bf223541c5515ab2691736f5a638ded HTTP/1.1" 200 None
2022-07-01T17:58:04.016000: DEBUG : using taskcluster route 'comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt'
2022-07-01T17:58:04.016000: DEBUG : using taskcluster route 'comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt'
2022-07-01T17:58:04.017000: DEBUG : taskcluster.client: Using method(v1, v2, payload) calling convention
2022-07-01T17:58:04.017000: DEBUG : taskcluster.client: Using method(v1, v2, payload) calling convention
2022-07-01T17:58:04.017000: DEBUG : taskcluster.client: Found a positional argument: comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt
2022-07-01T17:58:04.017000: DEBUG : taskcluster.client: Found a positional argument: comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt
2022-07-01T17:58:04.017000: DEBUG : taskcluster.client: After processing positional arguments, we have: {'indexPath': 'comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt'}
2022-07-01T17:58:04.018000: DEBUG : taskcluster.client: After processing positional arguments, we have: {'indexPath': 'comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt'}
2022-07-01T17:58:04.018000: DEBUG : taskcluster.client: After keyword arguments, we have: {'indexPath': 'comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt'}
2022-07-01T17:58:04.020000: DEBUG : taskcluster.client: After keyword arguments, we have: {'indexPath': 'comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt'}
2022-07-01T17:58:04.021000: DEBUG : taskcluster.client: Full URL used is: https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt
2022-07-01T17:58:04.021000: DEBUG : taskcluster.client: Full URL used is: https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt
2022-07-01T17:58:04.021000: DEBUG : taskcluster.client: Not using hawk!
2022-07-01T17:58:04.021000: DEBUG : taskcluster.client: Not using hawk!
2022-07-01T17:58:04.021000: DEBUG : taskcluster.client: Making attempt 0
2022-07-01T17:58:04.021000: DEBUG : taskcluster.client: Making attempt 0
2022-07-01T17:58:04.021000: DEBUG : taskcluster.utils: Making a GET request to https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt
2022-07-01T17:58:04.021000: DEBUG : taskcluster.utils: Making a GET request to https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt
2022-07-01T17:58:04.021000: DEBUG : taskcluster.utils: HTTP Headers: {}
2022-07-01T17:58:04.021000: DEBUG : taskcluster.utils: HTTP Headers: {}
2022-07-01T17:58:04.021000: DEBUG : taskcluster.utils: HTTP Payload: None (limit 100 char)
2022-07-01T17:58:04.022000: DEBUG : taskcluster.utils: HTTP Payload: None (limit 100 char)
2022-07-01T17:58:04.028000: DEBUG : urllib3.connectionpool: Starting new HTTPS connection (1): firefox-ci-tc.services.mozilla.com:443
2022-07-01T17:58:04.029000: DEBUG : urllib3.connectionpool: Starting new HTTPS connection (1): firefox-ci-tc.services.mozilla.com:443
2022-07-01T17:58:04.267000: DEBUG : urllib3.connectionpool: https://firefox-ci-tc.services.mozilla.com:443 "GET /api/index/v1/task/comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt HTTP/1.1" 404 440
2022-07-01T17:58:04.268000: DEBUG : urllib3.connectionpool: https://firefox-ci-tc.services.mozilla.com:443 "GET /api/index/v1/task/comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt HTTP/1.1" 404 440
2022-07-01T17:58:04.270000: DEBUG : taskcluster.utils: Received HTTP Status: 404
2022-07-01T17:58:04.270000: DEBUG : taskcluster.utils: Received HTTP Headers: {'Server': 'openresty', 'Date': 'Fri, 01 Jul 2022 16:58:04 GMT', 'Content-Type': 'application/json; charset=utf-8', 'Content-Length': '440', 'Content-Security-Policy': "report-uri /cspreport;default-src 'none';frame-ancestors 'none';", 'x-content-type-options': 'nosniff', 'x-for-trace-id': 'f4672fb72b8e47dfb9aa55f8dba7bf19', 'x-for-request-id': '1706499a-be98-40f4-aec2-bafccb7015dc', 'Access-Control-Allow-Origin': '', 'Access-Control-Max-Age': '900', 'Access-Control-Allow-Methods': 'OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT', 'Access-Control-Request-Method': '', 'Access-Control-Allow-Headers': 'X-Requested-With,Content-Type,Authorization,Accept,Origin,Cache-Control', 'Cache-Control': 'no-store no-cache must-revalidate', 'ETag': 'W/"1b8-9CJukRqeo+STJK9dWFsPG1Kz3wU"', 'Strict-Transport-Security': 'max-age=31536000', 'Via': '1.1 google', 'Alt-Svc': 'clear'}
2022-07-01T17:58:04.270000: DEBUG : nothing found via route 'comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt'
2022-07-01T17:58:04.270000: WARNING : Skipping build 424efa8d9bda: Unable to find build info using the taskcluster route 'comm.v2.comm-central.revision.424efa8d9bdaf3649a0aae4c613b1bd1cc40d078.thunderbird.win64-opt'
2022-07-01T17:58:04.272000: DEBUG : taskcluster.utils: Received HTTP Status: 404
2022-07-01T17:58:04.272000: DEBUG : taskcluster.utils: Received HTTP Headers: {'Server': 'openresty', 'Date': 'Fri, 01 Jul 2022 16:58:04 GMT', 'Content-Type': 'application/json; charset=utf-8', 'Content-Length': '440', 'Content-Security-Policy': "report-uri /cspreport;default-src 'none';frame-ancestors 'none';", 'x-content-type-options': 'nosniff', 'x-for-trace-id': 'ffdaab75094627962349b8c941e5fb6b', 'x-for-request-id': '5c59bda8-6ff8-43a1-a5dc-5b722d1e8f57', 'Access-Control-Allow-Origin': '', 'Access-Control-Max-Age': '900', 'Access-Control-Allow-Methods': 'OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT', 'Access-Control-Request-Method': '', 'Access-Control-Allow-Headers': 'X-Requested-With,Content-Type,Authorization,Accept,Origin,Cache-Control', 'Cache-Control': 'no-store no-cache must-revalidate', 'ETag': 'W/"1b8-3VhE9biZIaTzfnc3HA0JNj6Y22o"', 'Strict-Transport-Security': 'max-age=31536000', 'Via': '1.1 google', 'Alt-Svc': 'clear'}
2022-07-01T17:58:04.272000: DEBUG : nothing found via route 'comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt'
2022-07-01T17:58:04.272000: WARNING : Skipping build 5d39d63d0bf2: Unable to find build info using the taskcluster route 'comm.v2.comm-central.revision.5d39d63d0bf223541c5515ab2691736f5a638ded.thunderbird.win64-opt'
2022-07-01T17:58:04.273000: DEBUG : using taskcluster route 'comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt'
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: Using method(v1, v2, payload) calling convention
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: Found a positional argument: comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: After processing positional arguments, we have: {'indexPath': 'comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt'}
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: After keyword arguments, we have: {'indexPath': 'comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt'}
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: Full URL used is: https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: Not using hawk!
2022-07-01T17:58:04.273000: DEBUG : taskcluster.client: Making attempt 0
2022-07-01T17:58:04.273000: DEBUG : taskcluster.utils: Making a GET request to https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt
2022-07-01T17:58:04.273000: DEBUG : taskcluster.utils: HTTP Headers: {}
2022-07-01T17:58:04.273000: DEBUG : taskcluster.utils: HTTP Payload: None (limit 100 char)
2022-07-01T17:58:04.277000: DEBUG : urllib3.connectionpool: Starting new HTTPS connection (1): firefox-ci-tc.services.mozilla.com:443
2022-07-01T17:58:04.493000: DEBUG : urllib3.connectionpool: https://firefox-ci-tc.services.mozilla.com:443 "GET /api/index/v1/task/comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt HTTP/1.1" 404 440
2022-07-01T17:58:04.495000: DEBUG : taskcluster.utils: Received HTTP Status: 404
2022-07-01T17:58:04.495000: DEBUG : taskcluster.utils: Received HTTP Headers: {'Server': 'openresty', 'Date': 'Fri, 01 Jul 2022 16:58:04 GMT', 'Content-Type': 'application/json; charset=utf-8', 'Content-Length': '440', 'Content-Security-Policy': "report-uri /cspreport;default-src 'none';frame-ancestors 'none';", 'x-content-type-options': 'nosniff', 'x-for-trace-id': 'e83c12d400ef80e899639a036413a46f', 'x-for-request-id': '83d8e305-6dc5-4581-ac9e-716aa7c74a39', 'Access-Control-Allow-Origin': '', 'Access-Control-Max-Age': '900', 'Access-Control-Allow-Methods': 'OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT', 'Access-Control-Request-Method': '', 'Access-Control-Allow-Headers': 'X-Requested-With,Content-Type,Authorization,Accept,Origin,Cache-Control', 'Cache-Control': 'no-store no-cache must-revalidate', 'ETag': 'W/"1b8-XU1S1+Zzv/QpMe9kjG19bghePTE"', 'Strict-Transport-Security': 'max-age=31536000', 'Via': '1.1 google', 'Alt-Svc': 'clear'}
2022-07-01T17:58:04.495000: DEBUG : nothing found via route 'comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt'
2022-07-01T17:58:04.495000: WARNING : Skipping build 049490e47b58: Unable to find build info using the taskcluster route 'comm.v2.comm-central.revision.049490e47b58cc4450b2f442c4177e6a388321d4.thunderbird.win64-opt'
2022-07-01T17:58:14.449000: INFO : Stopped
-------------------------------------8<--------------------------------------------------------

Severity: normal → S3

I understand that I am using an Open Source program, and have no rights in terms of resolving this bug. I would really like to see this rather uninteresting bug fixed. I had hoped that running the bisection would have made it more straight forward, but it looks like it hasn't been picked up. I am now using 102.14.0 in windows, and something similarly up to date in Linux, and can confirm the problem is still there.

Thanks for the regression range. Sorry this didn't get picked up.

(In reply to Paul Jewell from comment #21)

Using the mozregression.exe:

  • comm-central build from 2017-03-17 is good
  • comm-central build from 2017-03-18 is no good.

Skimming the checkins, I'm not finding a smoking gun. Do you Magnus?

(In reply to Martin Trautmann from comment #20)

I can't do much about that regression range. For me it started with version 60, ongoing up to my current 78.13.0.

I don't understand what you mean - the tool is well documented and 95% of the work for you.

Flags: needinfo?(spam+bugzilla.mozilla.org)
Flags: needinfo?(mozillabugz)
Flags: needinfo?(mkmelin+mozilla)

Andy, Paul, a useful question at this stage is, does the problem reproduce with version 115 ?

Flags: needinfo?(paul)
Flags: needinfo?(mozillabugz)

(In reply to Wayne Mery (:wsmwk) from comment #24)

Andy, Paul, a useful question at this stage is, does the problem reproduce with version 115 ?

Yes, I still see it in 115.1 (Linux) as well as in 117.0b1 (Windows). To reproduce try to select one message, hit space bar until it advances to the next unread one, then click into the message itself. While the space key still scrolls down, at the end of the message it doesn't have any effect anymore, until you click once elsewhere.

Some debugging showed, that in this case cmd_space doesn't get propagated anymore, as if the browser widget itself immediately catches the space key event and handles it itself, so scrolling down still works, advancing does not.

Running v115.1.0

I just marked a few folders of email, and usenet groups as unread, then scrolled through messages using the space-bar, it did eventually get stuck on a message and required the "n" key to move past it.

However unlike before, when I re-marked the messages as unread, and scrolled through them again, it didn't get stuck at the same message a seond time.

It feels like it happens less often than before, let me try a few more times to see ...

Flags: needinfo?(mozillabugz)

(In reply to Hartmut Welpmann [:welpy-cw] from comment #25)

To reproduce try to select one message, hit space bar until it advances to the next unread one, then click into the message itself. While the space key still scrolls down, at the end of the message it doesn't have any effect anymore, until you click once elsewhere.

I can confirm that behaviour, bit it isn't the original problem I reported.
The original was about using only the space bar, with no re-focussing into the message pane.

(In reply to Andy Burns from comment #27)

I can confirm that behaviour, bit it isn't the original problem I reported.
The original was about using only the space bar, with no re-focussing into the message pane.

Does this also still happen in version 115?

Assignee: nobody → h.w.forms
Status: NEW → ASSIGNED

This fix at least seems to solve the problem for the situation I described in comment #25.

Flags: needinfo?(mkmelin+mozilla)

I've been trying to reproduce the original issue for a couple of days now, and can't get it to happen, so I think the changes behind v115 mean this problem no longer exists, if Hartmut's message pane focus problem is also fixed, I'd say this can be closed now?

(In reply to Andy Burns from comment #31)

I've been trying to reproduce the original issue for a couple of days now, and can't get it to happen, so I think the changes behind v115 mean this problem no longer exists, if Hartmut's message pane focus problem is also fixed, I'd say this can be closed now?

That is nice to hear. Please don't close the bug just yet, as my proposed fix still has to be reviewed. Thank you!

I've been investigating, since I'm not that happy with the proposed fix (it works, but causes some other problems), and I can make this happen every time:

  • Select a message in the list
  • Click once on the message content
  • Pressing space fires cmd_scrollPageDown as defined here
  • Click a second time on the message content
  • Pressing space fires cmd_space as defined by Thunderbird

The same thing happens if (while the message has focus) you switch to another window and come back. cmd_scrollPageDown runs until the message content is clicked on, and cmd_space happens after that.

One thing we could do is not connect the space bar to cmd_scrollPageDown (by an #ifdef in ShortcutKeyDefinitions.cpp) and get cmd_space to do it. This would work but involves changing mozilla-central and getting things uplifted to ESR. Or maybe we could override cmd_scrollPageDown somehow.

Emilio, do you have any idea why different commands would be fired depending on whether the content has been clicked on? It has focus in all cases, so the behaviour seems a little odd. Or do you have any other suggestions?

Flags: needinfo?(paul) → needinfo?(emilio)

I'm not the most familiar with how <key> elements are handled. I can dig with rr, but Masayuki might know off-hand?

Flags: needinfo?(emilio) → needinfo?(masayuki)

(In reply to Wayne Mery (:wsmwk) from comment #24)

Andy, Paul, a useful question at this stage is, does the problem reproduce with version 115 ?

Sorry Wayne - I have been away, so couldn't respond in a timely manner to this message. Gentoo doesn't package version 115, so I will look to make a local install and see if I can replicate the problem or not.

(In reply to Andy Burns from comment #5)

(In reply to Andy Burns from comment #4)

I found it would get "stuck" on some single email messages

It seems reproducible ... if I re-mark those messages as unread and try to
advance through them again,
it always seems to get stuck on the same ones again, I probably haven't
repeated that enough times to be absolutely sure it's always the same ones.

I've still not noticed anything in common between those it affects e.g. it's
nothing obvious such as html vs plain text.

I can confirm it seems to be certain messages which have this problem. I subscribe to a groups.io group, and read the messages in Thunderbird as emails with threading turned on. Going through a number of emails with <space> works, then I come across a message where it doesn't move to the next email. If I mark a number of earlier messages as unread, then start again, it stops at the same message. If I advance to the next message with 'n', then mark a number of messages as unread again (including the offending message), it stops again at the same point. I am using version 102.13.0, compiled locally on Gentoo. The message is stopped on during this experiment is html formatted, but some of the messages successfully passed are also html formatted.

Problem was originally reported as affecteing usenet messages, but later confirmed that it did affect some emails, I don't think the problem ever went away from v60 when I reported it up to v103, but I can't reproduce it on v115.

I do have a second machine still running v103, on email messages it does tend to get stuck on html formatted messages, it may always have only been html emails that were affected, but I can't say for sure.

I'm just subscribing to a couple of usnet groups on that v103 machine to check it's still affected, unlikely to encounter html messages in usenet.

(In reply to Andy Burns from comment #37)

Problem was originally reported as affecteing usenet messages, but later confirmed that it did affect some emails, I don't think the problem ever went away from v60 when I reported it up to v103, but I can't reproduce it on v115.

I do have a second machine still running v103, on email messages it does tend to get stuck on html formatted messages, it may always have only been html emails that were affected, but I can't say for sure.

I'm just subscribing to a couple of usnet groups on that v103 machine to check it's still affected, unlikely to encounter html messages in usenet.

Ok - so I was wrong about Gentoo packaging version 115 - it is in the repository, but masked (apologies to the Gentoo maintainer!). I have unmasked and installed it, and like you, can no longer replicate the issue with the space bar advancing to the following message. The font sizes have all changed, but I know I can fix that :).

Although it's not a clean approach, how about to set event="keydown" to the <key> element?

Flags: needinfo?(masayuki)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #39)

Although it's not a clean approach, how about to set event="keydown" to the <key> element?

It's tidier than the proposed patch for the same result, but it has the same adverse effects (controls that should handle the space button first don't get a chance to do what they do).

Any idea why it works after a second click but not after the first?

I'm going to investigate the viability of #ifdefing out the keys. I think it should be okay but will require replacement in each place that has a browser.

I'm still not sure what should be happened with which STR, though.

If found command is a XUL <key>, the event will be consumed unless it's disabled.
https://searchfox.org/mozilla-central/rev/f1f50693655c093d974f026bd37860d939cd5529/dom/events/KeyEventHandler.cpp#326

And also if the found command is a XBL command, the event is also consumed.
https://searchfox.org/mozilla-central/rev/f1f50693655c093d974f026bd37860d939cd5529/dom/events/KeyEventHandler.cpp#274

So I think that both of them never run with a key press operation.

cmd_scrollPageDown is registered as a <key> whose event type is keypress. Therefore, if Thunderbird registers a <key> with event="keydown", it's always tried because keypress is a default action of a keydown (i.e., keydown is always fired before keypress).

If cmd_space command were disabled, it'd be just skipped and cm_scrollPageDown will be executed later.
https://searchfox.org/mozilla-central/rev/f1f50693655c093d974f026bd37860d939cd5529/dom/events/GlobalKeyListener.cpp#344,346

If an element which should handle space keypress, cmd_space may block it because of the event order.

I'm not sure these things help you to understand the problems...

Any idea why it works after a second click but not after the first?

Sorry, I didn't answer this question. However, I have no idea. Could be caused by user activation check? I'm not familiar with that.

I'm trying to think how to make the default key assigns disabled or overridden, but I still don't get it yet.

One possible solution is giving id to each and make it disabled via chrome only API of Document. However, the shortcut is not duplicated per document, they are singleton in the process. So, it's hard to manage the state at focus move...

See Also: → 1830755

FWIW here the regression window. After that clicking into the message pane browser prevents advancing to the next message by space bar until the mouse just moves (!) anywhere else (out of the content area).

Keywords: regressionwindow-wanted
Depends on: 1854295
See Also: → 1847792
Attachment #9347745 - Attachment is obsolete: true
Assignee: h.w.forms → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: