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.
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
Turns out we have a duplicate VoidFunction callback in the WebIDLs. Per
Mozilla bug 1324169, we should remove this callback from
RTCPeerConnection.webidl and let Function.webidl handle it instead.
The AttributeError faced by the new Basilisk dev wasn't helpful at all;
and turns out Mozilla had this exact same issue on bug 1505504. We're
also backporting that just in case we encounter another case of
callback duplication.
Also doing a minor fix in the MicroTaskRunnable class which Moonchild
forgot to do while working on Issue #1895.
We already blocked x-moz-file(-promise) and x-moz-place* but of course people
would find ways to abuse other internal types. This change now blocks everything
except x-moz-url types which are harmless. (i.e. whitelist instead of blacklist)
This makes FetchStart use StartTime() when the TAO check fails for
PerformanceResourceTiming
Given the recent Fetch spec updates, Step 8.1 in
https://fetch.spec.whatwg.org/#finalize-and-report-timing specifies that start
time(StartTime) and post-redirect start time(FetchStart) should be start time
when the TAO check fails.
