Bugzilla

Sergey: adding you to Cc as this (two left clicks required) is the issue I discussed with you via private emails last year.

Bug 665728 is a request that would allow for a JS workaround for this issue. It has a simple test case as attachment 9351265 [details].

I am copying here the relevant content from my first email, **note especially the test cases relying on the current behaviour**:

I have grepped through the source code and commit history and debugged the code, but the location of the relevant code eludes me. For example, I recorded a session of clicking an input with a datalist and hitting down arrow with

./mach run --temp-profile --debugger=rr

Then I replayed it with `rr replay` and set a conditional breakpoint to sniff for down arrow events with

b gfx/layers/apz/src/KeyboardMap.cpp:150 if aEvent.mKeyCode==40

I dumped all of the steps to a file with

set pagination off
set logging enabled on
while 1
  step
end

Searching in the dump I could not find anything interesting.

Most recently I noticed I can definitely change the event handling by messing around with the switch cases in
https://hg.mozilla.org/mozilla-central/file/6462df7bf9184c6c728d00d99df71f72682618bc/toolkit/components/satchel/nsFormFillController.cpp#l873

Ie. building a change like

case eKeyDown:
  return Focus(aEvent);

makes down arrow stop working as normal in the input element. However, if I set a breakpoint in rr for the switch block, it is never reached.

**I have also noted down the automated tests that should be adjusted in case the behaviour change is accepted:**
mozilla-unified/accessible/tests/mochitest/events/test_focus_autocomplete.html
browser/components/extensions/test/browser/browser_ext_autocompletepopup.js

Sergey noted this in a reply to me:

"It looks like we intentionally prevent showing both the context menu and the autocomplete popup after right click"

Sergey: adding you to Cc as this (two left clicks required) is the issue I discussed with you via private emails last year.

Bug 665728 is a request that would allow for a JS workaround for this issue. It has a simple test case as attachment 9351265 [details].

I am copying here the relevant content from my first email, **note especially the test cases relying on the current behaviour**:

I have grepped through the source code and commit history and debugged the code, but the location of the relevant code eludes me. For example, I recorded a session of clicking an input with a datalist and hitting down arrow with

```
./mach run --temp-profile --debugger=rr
```

Then I replayed it with `rr replay` and set a conditional breakpoint to sniff for down arrow events with

```
b gfx/layers/apz/src/KeyboardMap.cpp:150 if aEvent.mKeyCode==40
```

I dumped all of the steps to a file with

```
set pagination off
set logging enabled on
while 1
  step
end
```

Searching in the dump I could not find anything interesting.

Most recently I noticed I can definitely change the event handling by messing around with the switch cases in
https://hg.mozilla.org/mozilla-central/file/6462df7bf9184c6c728d00d99df71f72682618bc/toolkit/components/satchel/nsFormFillController.cpp#l873

Ie. building a change like

```
case eKeyDown:
  return Focus(aEvent);
```

makes down arrow stop working as normal in the input element. However, if I set a breakpoint in rr for the switch block, it is never reached.

**I have also noted down the automated tests that should be adjusted in case the behaviour change is accepted:**
mozilla-unified/accessible/tests/mochitest/events/test_focus_autocomplete.html
browser/components/extensions/test/browser/browser_ext_autocompletepopup.js

Sergey noted this in a reply to me:

"It looks like we intentionally prevent showing both the context menu and the autocomplete popup after right click"