Open Bug 1658017 Opened 4 years ago Updated 4 years ago

I can right-click to get non-functional context menu everywhere on the account settings page

Categories

(Thunderbird :: Account Manager, defect)

Unspecified
All
defect

Tracking

(thunderbird_esr78 affected)

Tracking Status
thunderbird_esr78 --- affected

People

(Reporter: u665984, Unassigned)

References

Details

Attachments

(3 files)

Attached image right-click.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36 Edg/84.0.522.52

Steps to reproduce:

I didn't know if you were reporting the same problem.
If you are reporting the same, I apologize if it's the same.

Blank right click on the Account Settings menu page.
Normally, you should only be able to right-click in certain places.

Actual results:

In 78.1.1, I can right-click almost anywhere on the account settings page.
The situation is the same in 81.0a1.
A menu opens up and says "copy/select All".

Expected results:

Is this a bug?

Thunderbird 78.1.1 or 81.0a1 64bit Japanese
Windows10 64 bit 2004

Good find blue1620

I confirm seeing this on Mac. It offers Copy and Select all, but in fact nothing happens at all, and there isnothing in error console

Blocks: tb78found
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Summary: I can right-click everywhere on the account settings page → I can right-click to get non-functional context menu everywhere on the account settings page
Severity: -- → S4

More strange things on right-click in message list (probably unrelated):

  • unexpected context menu "Reload/stop/select all" (I've never seen this before, what is this?)
  • next context click on msg will show the correct message context menu (edit draft etc.)
  • focus still on first msg but we have right-clicked another msg (without modifier) which should move focus (also seen in TB68, maybe by design, but it's bad design which nobody expects so not much helpful)

I had a look at this using devtool's Event Listener Breakpoints on mouse > contextmenu.

Maybe Geoff knows more.

Adding conditional e.preventDefault() seems to fix it in a symptomatic way, but it's definitely not the right fix as it exploits the current faulty design. So this is just a pointer.

https://searchfox.org/comm-central/rev/f045b834713cbfb08b4fcc22f1923f93211ebce4/mozilla/toolkit/content/editMenuOverlay.js#106-108
EDIT: https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/toolkit/content/editMenuOverlay.js#106-108

  console.trace();
  console.dir(needsContextMenu);

  if (!needsContextMenu) {
    if (needsContextMenu === false) {
      e.preventDefault();
    }
    return;
  }

Observations:

  • A single right click on account settings background runs this code twice, with different values for needsContextMenu (first null, then false). That looks wrong in several ways:
    • Why twice?
    • Different returns for same click?
    • needsContextMenu should be boolean, not null.

console.trace() editMenuOverlay.js:106:11
<anonymous> chrome://global/content/editMenuOverlay.js:106
(Async: EventListener.handleEvent)
<anonymous> chrome://global/content/editMenuOverlay.js:96
null editMenuOverlay.js:107:11

console.trace() editMenuOverlay.js:106:11
<anonymous> chrome://global/content/editMenuOverlay.js:106
false editMenuOverlay.js:107:11

  • Unconditional e.preventDefault() will kill the undesired accounts right-click, but also kills right-clicks on messages in 3-pane. :-/
  • right-click on message in message list hits this code only once, with needsContextMenu === null.
  • So the above pseudo-fix exploits the difference between accounts and other right clicks by checking for false of accounts case and canceling the event. Again, clearly not the right fix (also not tested for other side effects).

@Geoff: ^^ comment 3 (as you have fixed context menus before)

Attached image right-click 2.jpg

I don't know the relevance of this right-click issue, but I will report it.

In ver.78, you can also right-click on the color picker or the number entry field.
You can also do it in the color picker or numerical entry field that does not require right click.
It is much more than ver.68.

Is this a specification?

(In reply to blue1620 from comment #5)

In ver.78, you can also right-click on the color picker or the number entry field.
Is this a specification?

No, maybe too broad conditional matching input here (localName tough, not tag):
https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/toolkit/content/editMenuOverlay.js#102
((["textarea", "input"].includes(e.composedTarget.localName) &&

For numbers, it might be ok, for colors, it currently does nothing.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: