1703208 - Nightly + macOS only: Context menu and autocomplete menu both come up when ctrl-clicking into a login username/password field for which login autofill is available

Status: NEW

(Toolkit :: Autocomplete, defect)

Description

[:Gijs (he/him)]

(Steps to reproduce are overly detailed - in some websites this will be easier to reproduce, but this "broke" reliably for me.)

STR (macOS-specific):

0. clean profile
1. Open https://accounts.google.com/
2. attempt any login and save it (doesn't need to be correct)
3. re-open https://accounts.google.com/
4. clear the username/email field, and then click outside of the login field to move focus elsewhere
5. ctrl-click the login field

ER:

only the context menu shows up

AR:

both the context menu and the autofill dropdown show up.

This appears to happen both with and without proton and/or native context menus enabled.

Comment 1

[:Gijs (he/him)]

Note that this doesn't happen when using the touchpad's right-mouse-button-click touch gesture (I use two-finger tap for this, but I imagine it's the same if you configure using the right/left corner for this in the macOS trackpad preferences)

Comment 2

[Edgar Chen [:edgar]]

I think it is caused by bug 1615732 where we report ctrl+left-mouse-buton-down as left button (now it is enabled on Nightly only). I think we need to do mac-specific check for mousedown event, like https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/browser/components/customizableui/content/panelUI.js#412-420.

Comment 3

[:Gijs (he/him)]

Indeed, it looks like turning off dom.event.treat_ctrl_click_as_right_click.disabled fixes this.

I'm not sure if the autocomplete code actually cares about the mouse events here or just listens for focus... but I guess it's an issue for the autocomplete code or DOM code to address, not the menu code, so moving components and clearing priority and proton tracking goop.

Comment 4

[Julien Cristau [:jcristau]]

Is there a bug tracking enabling the pref outside of nightly that this should block?

Comment 5

[Edgar Chen [:edgar]]

(In reply to Julien Cristau [:jcristau] from comment #4)

Is there a bug tracking enabling the pref outside of nightly that this should block?

Yes, bug 1703234 is for early beta and bug 1630962 is for all channel.
I make this blocking bug 1703234.

Comment 6

[Edgar Chen [:edgar]]

(In reply to :Gijs (he/him) from comment #3)

I'm not sure if the autocomplete code actually cares about the mouse events here or just listens for focus...

It seems like autocomplete cares more about the mouse event, as moving the focus to input field doesn't bring the dropdown list immediately, user needs to click the input field again to show the dropdown list. And the issue doesn't happen on every ctrl+click (if the focus isn't changed), seems only happen on the first one. Maybe autocomplete needs to do mac-specific check for ctrl+left-button case, too. Hi mak, could you shed some light here? Thanks!

Comment 7

[Marco Bonardo [:mak]]

Autocomplete is spread across various components: the controller in toolkit/components/autocomplete and the basic widget in toolkit/content/widgets (this bugzilla component refers to them), consumers in toolkit/components/satchel, and toolkit/components/formautofill.
I did some search in searchfox and I don't see obvious points where we manage the popup state on focus. Usually on focus we just setup things in the controller, or cache the focused element.

We definitely handle mouse events though, like here https://searchfox.org/mozilla-central/rev/287583a4a605eee8cd2d41381ffaea7a93d7b987/toolkit/components/satchel/nsFormFillController.cpp#1195-1220, and in those handler we may indeed open the popup (like in the example I posted, that may actually be related to this bug).