Based on selected bits of M-C 1461708:
- EventStateManager::CheckForAndDispatchClick() to early-return style
- split EventStateManager::CheckForAndDispatchClick() into:
EventCausesClickEvents, PostHandleMouseUp, DispatchClickEvents
- Move implementation of UIEvent::GetRangeParent() and UIEvent::RangeOffset() to nsLayoutUtils
nsPluginInstanceOwner only listens to keypress events in the default event group.
However, in our changed operating mode, keypress events are not fired in the
default event group if the key does not result in something printable.
This means that nsPluginInstanceOwner should also listen to keypress events
in the system event group and should handle each keypress that way, but
only once. I.e., if a printable keypress event is received in the system event
group, it should be ignored, since it would've already been handled in the
default event group in that case.
Following the behavior of the download dialog, the content handling dialog should be `dependent` as well. This means that this dialog should close when the parent window is closed, is not visible on the taskbar, and stays in front of the parent window.
Based on FranklinDM's follow-up for the issue.
This would require browser FE changes, particularly removing the associated
code in `tabbrowser.xml`, however, that was already done in Pale Moon previously.
Other front-end applications may need to take note, though.
Based on changes from the following bugs:
* Bug 696398 - Need an api to analyze panning performance
* Bug 800031 - Include paint time in tab switch telemetry
* Bug 820167 - Enable performance measurement of tab animation
* Bug 826383 - Improve Start/Stop FrameTimeRecording for telemetry usage
The autocomplete module listens to keypress events for both printable keys
and non-printable keys a lot. However, we're stopping dispatching keypress
events for non-printable keys in the default event group of web content.
This means that autocomplete should listen to keypress events in the
system event group.
Note that it's difficult to globally change keypress event listeners to
keydown event listeners because if we stop keypress events at preceding
keydown event in autocomplete or satchel modules, some other modules
fail to handle keydown or keypress events before autocomplete, and it's
not easy to investigate which keypress event listener in which modules
should be changed to a keydown event listener.
Therefore, this patch doesn't do that, and uses the event group approach.
Since keypress is no longer triggered on all keypresses in content,
the spellchecker would potentially not be triggered when it should be.
This changes the trigger to keydown, instead.
No behavioral changes otherwise.
This will prevent the keypress DOM event from firing on keypresses
that do not produce printable keys (e.g. editing nav keys) in content.
This should not affect any chrome events that are in use.
Event dispatch can be re-enabled if necessary with the added pref.
