I have been spending some time figuring out this issue and deduced the following. My opinion is that the "simulated right-click" happens a few pixels too low.
The events happen like this:
- The native back-end (e.g. GTK) is receiving a KeyPressEvent. If the "Context Menu" key is pressed, it will convert this into a nsMouseEvent, with coordinates (0,0) and the context type nsMouseEvent::eContextMenuKey (mozilla/widget/src/gtk2/nsWindow.cpp @ 3296)
- As the event propagates, nsEventListenerManager::FixContextMenuEvent() is called, which sets the coordinates to that of the caret, using PrepareToUseCaretPosition (mozilla/content/events/src/nsEventListenerManager.cpp @ 1422)
I doubt that the nsCaret's coordinates are wrong (else this might also create weird drawing artifacts), so I think the problem is related to how PrepareToUseCaretPosition processes this value.
I haven't got any more energy to study this, so it would be really cool if somebody could take over.
Hello,
I have been spending some time figuring out this issue and deduced the following. My opinion is that the "simulated right-click" happens a few pixels too low.
The events happen like this:
- The native back-end (e.g. GTK) is receiving a KeyPressEvent. If the "Context Menu" key is pressed, it will convert this into a nsMouseEvent, with coordinates (0,0) and the context type nsMouseEvent: :eContextMenuKe y (mozilla/ widget/ src/gtk2/ nsWindow. cpp @ 3296) Manager: :FixContextMenu Event() is called, which sets the coordinates to that of the caret, using PrepareToUseCar etPosition (mozilla/ content/ events/ src/nsEventList enerManager. cpp @ 1422)
- As the event propagates, nsEventListener
I doubt that the nsCaret's coordinates are wrong (else this might also create weird drawing artifacts), so I think the problem is related to how PrepareToUseCar etPosition processes this value.
I haven't got any more energy to study this, so it would be really cool if somebody could take over.