Introduce internal events for existing network events and monitor them from browsingContext.navigate to ensure a responseCompleted event
was received before resolving the command.
Differential Revision: https://phabricator.services.mozilla.com/D191609
DrawTargetWebgl relies upon DrawShadow for shadow performance. This was never
implemented in DrawTargetRecording, which this patch rectifies.
Differential Revision: https://phabricator.services.mozilla.com/D194354
Chartjs heavily relies on circle drawing, which dispatches to the FillCircle and
StrokeCircle hooks in DrawTarget. These need to be implemented in DrawTargetWebgl.
Differential Revision: https://phabricator.services.mozilla.com/D194353
This adds the necessary infrastructure for CanvasTranslator to allocate DrawTargetWebgl
instead of just allocating TextureData, and to use RemoteTextureMap to handle sending
the DrawTargetWebgl frames to the compositor.
This optimizes snapshot transport to use fewer copies to and from shmems when we know
the snapshot contents can be sourced from a shmem.
This adds a blocking mechanism separate from deactivation so that existing DrawTargetWebgls
can continue processing events while denying further ones from being created in the event
that allocating further DrawTargetWebgls might cause problems, but so that we don't disrupt
canvases that are already in flight.
PersistentBufferProviderAccelerated still remains the buffer provider for the new setup,
but just allocates a single RecordedTextureData internally. Since DrawTargetWebgl already
does its own swap chain management internally, we do not want to use the multiple texture
client strategy that PersistentBufferProviderShared does.
This adds a fallback mechanism such that if DrawTargetWebgl allocation fails, a TextureData
is allocated instead that still sends results to RemoteTextureMap. This has the advantage
that we don't need to synchronously block in the content process to verify if acceleration
succeeded, as the costs of such blocking are rather extreme and we must still produce the
rendered frame to ensure the user sees the correct result if the speculative acceleration
failed. It then notifies the content process asynchronously via the refresh mechanism to
try to recreate a non-accelerated buffer provider when it is ready.
There is one additional hitch in RemoteTextureMap that we need to add a mechanism to deal
with the setup of the RemoteTextureOwner. When display list building initially needs to get
the remote texture, the RemoteTextureOwner might not exist yet. In this case, we need to add
a block to ensure we wait for that to occur so that we do not render an erroneous result.
Previously, this block was handled in ClientWebGLContext. Since that is no longer used,
the block must be reinstated somewhere else until a non-blocking mechanism for display list
building to proceed with a stub texture host wrapper can be implemented.
Currently this leaves the gfx.canvas.remote and gfx.canvas.accelerated prefs as separate
toggles rather than trying to lump everything into one mechanism. While this may be desirable
in the future, currently Direct2D remote canvas is a separate acceleration mechanism that
needs to co-exist with the WebGL acceleration, and so being able to toggle both on or off
for testing is desirable.
Differential Revision: https://phabricator.services.mozilla.com/D194352
This mostly restructures DrawTargetWebgl to no longer rely upon ClientWebGLContext.
Instead, it must directly interact with WebGLContext which requires some noisy changes
of the GL rendering API used.
In addition, this restructures SharedContextWebgl so that it can be explicitly
allocated and further DrawTargetWebgls can be allocated that feed off of it.
This is all towards the ultimate goal of relying on remote canvas infrastructure for
remoting instead.
Differential Revision: https://phabricator.services.mozilla.com/D194351
On a given thread, if there are outside users of OpenGL (such as WebRender) that don't go
through the GLContext interface to set the current context, the TLS current context value
may be incorrect. To solve this, we need to assume that on establishing some TLS scopes,
that the current context value is unreliable and invalidate it so that it gets properly
reset.
Differential Revision: https://phabricator.services.mozilla.com/D194350
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
DrawTargetWebgl is transitioning away from using ClientWebGLContext, so
local extensions that were added to support that use-case are no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D194346
Prior to this change, --disable-optimize clobber builds on macOS took 50%
longer. Build telemetry shows over 80% of developer builds on macOS use
--disable-optimize.
The defaults for HOST_OPTIMIZE_FLAGS that are set in old-configure.in can be
overriden by setting the variable in your mozconfig. For example, setting:
HOST_OPTIMIZE_FLAGS=-O1
Differential Revision: https://phabricator.services.mozilla.com/D195459
Some time after bug 1237610 originally added telemetry gathering to the build
process, the code changed to gather it via Glean in bug 1651424. Later, bug
1867968 removed some of the old code, but it missed the removal of
get_build_opts. This change removes that function and a few other functions in
the same file that appear to be unused.
Differential Revision: https://phabricator.services.mozilla.com/D195354
Retrieving the security information happens asynchronously and can happen after the response content was received.
The test should wait for both flags to be set before resuming.
Differential Revision: https://phabricator.services.mozilla.com/D195436
As part of other changes, bug 1856582 removed newlines at the end of
record_warning() and record_error() messages. But most uses of these
macros don't put newlines in themselves. This meant that warnings and
errors in glxtest output were missing newlines and so the following line
would get appended to the error/warning message. This could break
various things depending what the next line after the error/warning was
meant to be.
Differential Revision: https://phabricator.services.mozilla.com/D194997
The test case is a special case that changes focused element from a text control
to an editing host. Therefore, without a focus change, focused editor is
changed from a `TextEditor` to `HTMLEditor`. At this time, `IMEContentObserver`
needs to switch the observing target from the anonymous content if `<input>` to
children of it.
However, the editable content becomes completely changed without a focus change
in the DOM. Therefore, `IMEStateManager` needs to synthesize a fake focus move
for IME. Therefore, this patch make `IMEStateManager` recreate
`IMEContentObserver` if active one is not observing editable content for the
focused element under "current" conditions at checking it. (When
`IMEContentObserver` is being destroyed, it sends "blur" notification to IME
and the new `IMEContentObserver` instance posts "focus" notification with
all editable content data. I.e., recreating `IMEContentObserver` generates
a fake focus move from IME point of view.)
Additionally, there is the opposite case, that is, editing host of an `<input>`
whose type is not a text control may become a text control. Therefore, this
adds new WPTs to check the handler is the text editor for the text control or
the HTML editor. The tests passed on Firefox and Chrome at least.
FYI: I guess that in this case, we need to kick `focus` event listener of the
`HTMLEditor`, but anyway, users cannot change the content because it's the
case that an atomic content is the editing host. Therefore, I don't touch
about that in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D193262
When the http3server prints a bunch of stuff and dies, the loop doesn't
actually have the time to read multiple lines before poll returns
something, breaking the loop... leaving the log without possibly vital
information.
Unfortunately, since killing the process in stop can also lead to
the threads being blocked on readline (see bug 1863675), we also need to
stop joining the threads. If the process terminates normally, the loop
will break itself when the pipe returns nothing, and the threads will
exit on their own.
Differential Revision: https://phabricator.services.mozilla.com/D195207
When http3server doesn't print its "server listening" message, it likely
has printed some other important stuff, but we're only capturing and
printing the first line of stdout in that case. In most cases, the
important stuff would be on stderr, so there isn't even a hint of what's
wrong in the printed output.
By always launching the reader threads, we ensure that any output from
http3server makes it to the log. We also print a hint that the server
may not have started properly.
Differential Revision: https://phabricator.services.mozilla.com/D195206
ClearKey and Widevine L3 are used in the GMP process, so comparing with
MFCDM, we need to use another different way to access their capabilities.
Differential Revision: https://phabricator.services.mozilla.com/D194932
This patch implements retrieving the capabilities from MFCDMs. I will
add non-MFCDM support in following patches, eg. Widevine L3, and
ClearKey.
Differential Revision: https://phabricator.services.mozilla.com/D194837
We reconfig the debug info by using space to separate each attribute,
which would help us process them easier when showing the information in
`about:support` later.
Differential Revision: https://phabricator.services.mozilla.com/D194841
Doing this can help to save the time loading the new factory, because
the factory can be reused.
In addition, during testing, I also found out that Widevine L1 dll's
`ActivateInstance` is not thread safe. If we access that on two
different threads, only one thread can load factory successfully.
Therefore, I added a mutex to guard the process of loading factory.
Differential Revision: https://phabricator.services.mozilla.com/D194835
We want to have a method that can report capabilites from all key
systems so that we can display those information in the `about:support`
later, which will be implemented in following patches.
Differential Revision: https://phabricator.services.mozilla.com/D194451
The wrench-deps tasks should trigger when webrender-related Cargo.tomls
are updated, and it should fail when they are updated, but the
corresponding Cargo.lock isn't.
Differential Revision: https://phabricator.services.mozilla.com/D195317
Mike Hommey
Julien Cristau
Florian Quèze
Julian Descottes
Cosmin Sabou
Lee Salzman
Jonathan Watt
Alexandra Borovova
Emilio Cobos Álvarez
Mozilla Releng Treescript
David Turner
Nipun Shukla
Iulian Moraru
Masayuki Nakano
Otto Länd
Jan Varga
alwu
Natalia Csoregi
Sidharth Sachdev
Steve Fink