The code path that was used for loading a document
with fission disabled did not take user activation into account.
This made almost all WPTs for Text Fragments fail,
since they depend on this flag to decide if
a text directive is allowed to be scrolled to.
This patch makes sure that the user activation is
also available for code paths that run through
`CanonicalBrowsingContext::FixupAndLoadURIString()`
to load a document.
This is done by adding a flag `hasValidUserGestureActivation`
to the `nsIOpenWindowInfo`, which carries it through
the JS stack for loading a document.
Differential Revision: https://phabricator.services.mozilla.com/D213401
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
The code path that was used for loading a document
with fission disabled did not take user activation into account.
This made almost all WPTs for Text Fragments fail,
since they depend on this flag to decide if
a text directive is allowed to be scrolled to.
This patch makes sure that the user activation is
also available for code paths that run through
`CanonicalBrowsingContext::FixupAndLoadURIString()`
to load a document.
This is done by adding a flag `hasValidUserGestureActivation`
to the `nsIOpenWindowInfo`, which carries it through
the JS stack for loading a document.
Differential Revision: https://phabricator.services.mozilla.com/D213401
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
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
The dropped item is set on drop event handler in Android. Current
Gecko's implementation caches dropped item as `DataTransfer` when any
drag events are fired. It will works on desktop platform, but doesn't
on GeckoView. Even if drop item is set by handling drop event,
`DataTransfer`'s cache isn't refreshed.
So if drop event is received, we re-fill DataTransfer on GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D197331
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
In bug 1755863, we introduce two async APIs in `nsIClipboard` to make async
clipboard API reads the clipboard data asynchronously. When reading, async
clipboard API first check the available types, and then retrieve the actual data
for that type. This process has a potential race condition: the clipboard content
might change between the time between the time we check the types and when we
retrieve the data. Although we currently fetch the actual data immediately after
checking available types (in line with the spec), this minimizes the chance of
encountering this race condition. However, if we would like to support retrieving
the data only when `getType()` is invoked (bug 1691825), this potential race
condition could become a significant issue.
Furthermore, bug 1777448 aims to have a way to track the clipboard data and suppress
the paste context menu when the clipboard data originates from a same-origin page.
This also requires a better way to track read requests, clipboard content and
invalidate the request when the system's clipboard content is changed.
After some refacting around nsBaseClipboard, all platform now use sequence
number to track clipboard content, so `nsIAsyncGetClipboardData` can be associated
with a sequence number and deemed invalid if the associated sequence number isn't
matched the latest system value.
With these new API, it also becomes possible to write some tests.
Depends on D191409
Differential Revision: https://phabricator.services.mozilla.com/D182108
