These functions aren't available to content and we don't want to support
large lengths there, so just report an exception.
Depends on D111382
Differential Revision: https://phabricator.services.mozilla.com/D111383
Recently we use fast track clipboard shortcut to get clipboard data when clipboard content is owned by Firefox but
we ask Wayland compositor for clipboard content mime types.
That may lead to a bug when Firefox is faster and sets clipboard content internally but Wayland compositor does not have the content yet.
So use fast track to also get clipboard mime types.
Differential Revision: https://phabricator.services.mozilla.com/D111377
We have to consider mobile viewport scale to calculate screen position.
And mozInnerScreen isn't valid position if that scale isn't 1 (bug 1701546).
Also, this function won't work on Fission+xorigin with mobile viewport due to
no way to get current mobile viewport scale since window.top isn't same
origin.
Differential Revision: https://phabricator.services.mozilla.com/D110198
The editing session is temporarily disabled when opening a document. Then,
when the document is closed, the editing session is restored with same
`HTMLEditor` instance. Therefore, initializing editor may occur during
an edit action is being handled.
Probably, this must not be used in normal webapps since mutation events are
used rarely. So, I think that for avoiding further complicated things, we
should make editor won't accept new edit action handling after original
editing session ended.
This patch renames `AutoEditActionDataSetter::CanHandle()` to
`IsDataAvailable()` since it just checks whether the important resource is
available or not. And makes new `CanHandle()` return `false` for
non-initializing edit actions if editing session has ended.
Differential Revision: https://phabricator.services.mozilla.com/D111241
Now that we can report long URI errors to the app using `NavigationDelegate`,
I have updated the tests accordingly.
I also added a test to ensure that long `data:` URIs are still accepted when we
are not dealing with a toplevel document. We generate a PNG image filled with
randomness, which compresses poorly (and thus is "large") and yet is a valid PNG
file. We expect its `onload` event to fire.
Differential Revision: https://phabricator.services.mozilla.com/D109429
While I evaluated multiple approaches to this problem, I selected two:
The first is to handle the case in `GeckoSession.load` directly from within
Java, as this allows us to avoid a Java to Native string conversion, as well as
giving us better opportunities to report the exact nature of the failure back to
the embedding app.
We add a new error code specifically for this case.
In the case where no `NavigationDelegate` is registered, I used
`GeckoSession.load` throwing an exception as a crude way of notifying the app.
In the case where the load request originates from within web content, we deny
the request from within `nsWindow` to avoid requiring any conversion of the
URI spec from native into Java.
Differential Revision: https://phabricator.services.mozilla.com/D109427
For webcompat reasons, we have determined that we should only limit the length
of URIs in specific cases. We're going to handle this on the GV side instead.
Differential Revision: https://phabricator.services.mozilla.com/D109426
When given point is **in** a void element, e.g., this can be when JS inserts
nodes into a void element like `<meta>`,
`HTMLEditor::SplitNodeDeepWithTransaction` may return "not handled" state.
So, it's possible case, we shouldn't assert the case.
This patch adds both WPT and crashtests because I couldn't reproduce it
with WPT's simpler API use.
Differential Revision: https://phabricator.services.mozilla.com/D111231
When toggling debug state, we can sometimes queue debug renders, without
any debug overlay to send them to. This patch ensures we don't actually
draw anything in the debug renderer when there is no debug overlay.
Differential Revision: https://phabricator.services.mozilla.com/D111355
If we fail to map in a shared surface that we support unmapping for,
don't OOM crash immediately if this is the first time we are mapping it.
This is because we probably freed up a bunch of virtual memory already
purging the expiration tracker, but on Windows, this may take some time
before the virtual address space is available for reuse. Since there
will be some time gap between the mapping and the frame rendering, this
may be sufficient time to recover in some cases, avoiding a GPU process
OOM crash.
This should only affect 32-bit users, since we never unmap on 64-bit
builds.
Differential Revision: https://phabricator.services.mozilla.com/D111270
WebRenderAPI::DestroyRenderer() destroys RendererOGL and WebRender's Renderer instance. After RendererOGL is destroyed, RenderBackend could not sent message to WebRender's Renderer via RenderBackend::result_tx.
Message sending by RenderBackend::result_tx needs to be stopped after destroying WebRender's Renderer instance.
After wr_api_stop_render_backend() call, RemoveRenderer have to be called via wr_api_send_external_event(). It actually destroys the renderer. Its message arrives when WR backend is in RenderBackendStatus::StopRenderBackend state. At the time, WR backend is stopped sending message to renderer.
Differential Revision: https://phabricator.services.mozilla.com/D110795
Jan de Mooij
Sebastian Hengst
Emilio Cobos Álvarez
Andrei Oprea
Marco Bonardo
Christoph Kerschbaumer
Timothy Nikkel
Andreas Farre
smolnar
stransky
Nihanth Subramanya
Alex Ionescu
Michelle Goossens
Makoto Kato
Bob Owen
Harry Twyford
Julian Descottes
Masayuki Nakano
Daisuke Akatsuka
Lee Salzman
Henrik Skupin
Tom Tung
Aaron Klotz
Alexandru Michis
Drew Willcoxon
Gijs Kruitbosch
Andrew Osmond
sotaro
Kagami Sascha Rosylight
Andrew McCreight