The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
This reference created a cycle after the strong Manager() reference added in an earlier part.
With the reference removed, the VsyncChild will be kept alive via the IPC link
instead, and will be torn down when the IPDL actor is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D198626
If session history in the parent is enabled then session store only works
correctly if the platform collection code is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D203375
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
This reference created a cycle after the strong Manager() reference added in an earlier part.
With the reference removed, the VsyncChild will be kept alive via the IPC link
instead, and will be torn down when the IPDL actor is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D198626
Reflect modifiers to chromeFlags and nsIBrowserDOMWindow::OPEN_* location,
to perform the equivalent of BrowserUtils.whereToOpenLink in window.open with
modifier keys.
Differential Revision: https://phabricator.services.mozilla.com/D197864
Pass UserActivation::Modifiers from nsGlobalWindowOuter::OpenInternal
to nsPIWindowWatcher.openWindowWithRemoteTab, through the following interfaces
and protocol:
* nsPIWindowWatcher.openWindow2
* nsIWindowProvider.provideWindow
* PContent.CreateWindow or PContent.CreateWindowInDifferentProcess
* nsPIWindowWatcher.openWindowWithRemoteTab
Differential Revision: https://phabricator.services.mozilla.com/D197863
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
- Ensure that we hold a strong reference to the APZ event state before
calling ProcessSingleTap, as ProcessSingleTap fires events.
- Mark ProcessSingleTap as MOZ_CAN_RUN_SCRIPT since it can fire events.
Differential Revision: https://phabricator.services.mozilla.com/D190228
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
This should not be needed anymore. We no longer need to "ack" an epoch,
since there's no epoch.
Make the logic to trigger a paint and request composite a bit more
generic. That doesn't change behavior right now, because our visibility
state is tied to mRenderLayers, but without this change setting
renderLayers = true on a display: none iframe will trigger a useless
paint after bug 1847584.
Differential Revision: https://phabricator.services.mozilla.com/D187293
This seems to work, and turns out I need to fix this before bug 1847584,
because the epoch handling breaks with those patches in the case
customize mode sets display: none on browser elements.
Instead of dealing with epochs, just always report the last "has layers"
state to BrowserParent. This is both simpler and more reliable (there
were a couple hacks in WebRenderBridgeParent to make sure we notified
even though a transaction failed).
AsyncTabSwitcher pretty much already deals with this correctly because
it already needs to deal with browsers that already have layers, we only
had to loosen some assertions for potentially previous messages which
are fine.
Differential Revision: https://phabricator.services.mozilla.com/D187203
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
Use edge-inclusive intersection like IntersectionObserver, to make
zero-size iframes that are in the viewport considered visible. This is
consistent with how we treat zero-sized in-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D185808
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
This partially backs out bug 774398.
This code was added to match what Chromium was doing, but it seems (per
discussions with Chromium engineers) that:
* Resize event listener in Chromium never changed
innerWidth/innerHeight. That doesn't match my recollection from bug
774398, but it's true now in Chrome stable, at least.
* Chromium canary no longer fires a resize event
(https://crbug.com/1076867).
* WebKit doesn't fire resize either.
So let's get rid of this, which also causes some correctness issues with
some iframes, and keep just the media query listeners firing.
Differential Revision: https://phabricator.services.mozilla.com/D185404
For handling (ignoring) "too late" composition commit request from content
process, we need to distinguish a request is for which composition. Therefore,
we need to number each composition originated in the parent process.
This patch makes `TextComposition` instance which is created at first
composition event for a composition consider a composition ID in the parent
process and set it to composition events which are dispatched into the DOM
tree in the parent or sent to a remote process.
And also this patch adds the composition ID param to the request method of
committing composition and reply methods to notify the parent process of ending
a composition event handling.
The last patch handle them in `ContentCacheInParent` to consider
whether a request/reply should be ignored or handled.
Differential Revision: https://phabricator.services.mozilla.com/D179310
For handling (ignoring) "too late" composition commit request from content
process, we need to distinguish a request is for which composition. Therefore,
we need to number each composition originated in the parent process.
This patch makes `TextComposition` instance which is created at first
composition event for a composition consider a composition ID in the parent
process and set it to composition events which are dispatched into the DOM
tree in the parent or sent to a remote process.
And also this patch adds the composition ID param to the request method of
committing composition and reply methods to notify the parent process of ending
a composition event handling.
The last patch handle them in `ContentCacheInParent` to consider
whether a request/reply should be ignored or handled.
Differential Revision: https://phabricator.services.mozilla.com/D179310
