In current m-c, async RemoteTexture wait at RenderThread stops window update when the wait is too long. If async RemoteTexture is handled by WebRenderAPI, window could be updated during long async RemoteTexture wait.
async RemoteTexture wait of root WebRenderBridgeParent are disabled to simplify WebRenderAPI's wait handling.
offscreen canvas case is handled by WebRenderImageHost by Bug 1827578.
Differential Revision: https://phabricator.services.mozilla.com/D175590
Turns out both `OPEN_FIREFOX_VIEW` and `OPEN_FIREFOX_VIEW_AND_COLORWAYS_MODAL` just call `window.FirefoxViewHandler.openTab();`, so not only is this action kinda misleading now that the Colorways closet is gone, it's a duplicate action.
Differential Revision: https://phabricator.services.mozilla.com/D175792
This notification will help Thunderbird developers who are tasked with pushing
multiple bugs to comm-central after a mozilla-central push.
Taskgraph tests adjusted to verify the notification is only sent for pushes
to mozilla-central, and to run the tests when .taskcluster.yml is updated.
Differential Revision: https://phabricator.services.mozilla.com/D175290
Previously we would both send it as the routing target for the actor as
well as as an implicit actor parameter. This patch keeps the same API
from the caller's point of view, but avoids sending the second reference
to the actor in the Send__delete__ message, which also avoids potential
issues with the second reference being null under fuzzing.
Differential Revision: https://phabricator.services.mozilla.com/D175545
When necko makes a speculative connection, the peer may ask for a client
authentication certificate. This patch makes it so that when this happens,
no certificate selection UI will be shown until the connection is claimed (as
in, it is no longer merely speculative).
Differential Revision: https://phabricator.services.mozilla.com/D175528
We use many variations of 'global data', 'global area', and more recently
'instance data'. I prefer 'instance data' as 'global' is ambiguous with
wasm globals, which while stored in the instance are not the only thing
stored there. The naming scheme for this originated when globals were
the only thing stored there, so we should now change it.
Depends on D172026
Differential Revision: https://phabricator.services.mozilla.com/D172027
BaseCompiler::loadTypeDef assumes that it can use InstanceReg, but that
is only true on non x86/arm32.
This commit removes loadWasmGlobalPtr, as it's just a thin wrapper around
loadPtr that obscures more than helps. Callers of that now just specify
the register that contains the instance directly. This demystifies what's
going on. We can then fix baseline to use a register it has allocated.
Differential Revision: https://phabricator.services.mozilla.com/D172026
Previously we would both send it as the routing target for the actor as
well as as an implicit actor parameter. This patch keeps the same API
from the caller's point of view, but avoids sending the second reference
to the actor in the Send__delete__ message, which also avoids potential
issues with the second reference being null under fuzzing.
Differential Revision: https://phabricator.services.mozilla.com/D175545
Currently the new platform and task names are getting stuck as the first test being analyzed. This patch fixes it by changing how those two values are setup.
Differential Revision: https://phabricator.services.mozilla.com/D175246
This implements the weather suggestion result menu UI and builds on D174941.
References:
* [Spec]( https://www.figma.com/file/Hdi0oHB7trRcncyVAKZypO/accuweather-explorations?node-id=2421%3A62540&t=29w6wH3UYchqBxqX-1) (See "A11y review" in the sidebar)
* [Clickable prototype](https://www.figma.com/proto/Hdi0oHB7trRcncyVAKZypO/accuweather-explorations?page-id=2192%3A42825&node-id=2394-52468&viewport=246%2C526%2C0.12&scaling=min-zoom&starting-point-node-id=2394%3A52468&show-proto-sidebar=1) (See "Revised 4/3" in the sidebar)
There are a couple important points about the menu. First, one of the commands,
"Report inaccurate location", is specific to weather suggestions, or at least
location-based suggestions. I don't think it's a good idea to centralize all
commands in UrlbarView, and in general I'd like to stop centralizing handling of
different result types in the view and input, so I added a new provider method
called `getResultCommands()`.
Second, the spec calls for a menu separator and a submenu so the user can select
a reason they don't want to see the result, so the return value of
`getResultCommands()` is flexible enough to support those two things, and I
modified `#populateResultMenu()` too.
These new commands will be recorded in Glean engagement telemetry as new
`engagement_type` values, same as "dismiss" and "help" currently are.
This patch doesn't implement handling of two of the commands, "Report inaccurate
location" and "Show less frequently", because I wanted to keep it focused on the
fundamentals described above.
Depends on D174941
Differential Revision: https://phabricator.services.mozilla.com/D174994
This test aspires to be a simple example of how repeated requests to enter
and exit fullscreen stress the fullscreen handling code.
Differential Revision: https://phabricator.services.mozilla.com/D174797
This change makes the parent process delay a fullscreen request if there
is a pending fullscreen exit. It also changes the DOMFullscreenParent
actor listener lifecycle. Once it has started handling a fullscreen
request, it will remain a listener to the Document until it receives an
exit event when the manager is out of fullscreen.
Differential Revision: https://phabricator.services.mozilla.com/D175186
This change relaxes the check slightly. Spec requires that the tab is
focused. Our existing check for "active" is additionally requiring the tab
to be non-occluded. Since occlusion updates are asynchronous when the
transition itself is asynchronous, this change allows rapid requests to be
permitted as long as the underlying window and tab state is as expected.
Differential Revision: https://phabricator.services.mozilla.com/D174983
This seems to be here since nsTextControlFrame has a meaningful
baseline, but it doesn't make much sense to me:
* Baseline is a block axis, not inline axis measurement.
* It doesn't call into the base class which seems clearly a bug (though
the intrinsic isize of the input is ~fixed, doesn't depend on font
metrics, so it's probably ok).
My guess is that it was intended to be a debug-only check so that we
could detect stale baseline values.
Just remove this, and replace it by a non-fatal assert as it's done
elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D175745
This isn't needed for nsTextControlFrame because its ComputeAutoSize
implementation doesn't return an unconstrained line-height for inputs,
so we never end up in the UNCONSTRAINEDSIZE case, but it's needed for
date/time inputs.
Use GetLineHeight while at it, since it's the inflated line-height which
is what we want, and may be cached so we can avoid computing it.
Maybe in the future we can make date/time inputs just use
nsTextControlFrame, which would prevent this from happening in the
future.
Depends on D175745
Differential Revision: https://phabricator.services.mozilla.com/D175746
Prefer timestamp from the OpenH264 decoder if available.
This patch bumps the API version for the GMP plugin API. The OpenH264
library takes advatange of this. It also adds a few quality of life
options. One request the GMP library logging be turned on via the
"GMPLibrary" log module. One can toggle between single and
multi-threaded decoding via media.gmp.decoder.multithreaded. One can
toggle between single or batch decoding via
media.gmp.decoder.decode_batch.
Provided the OpenH264 library supports this, it will now provide the
adjusted presentation timestamp from the decoder. This is necessary for
encodings with B frames that may be out of order. This corresponds to
the SBufferInfo::uiOutYuvTimestamp from the library. If it is not
available, we will default to our historical behaviour and use the
original presentation timestamp.
Additionally, we now assume that H264 frames may also be provided out of
order, and we provide a reorder queue to buffer the input similar to the
other H264 decoders such as Apple's and Widevine's. This will ensure
that regardless of the plugin output, we will provide any necessary
reordering.
Differential Revision: https://phabricator.services.mozilla.com/D175281
This patch moves some code to properly handle the max number of tasks better, and considers the --rebuild setting when we check if there are too many tasks selected.
Differential Revision: https://phabricator.services.mozilla.com/D174261
