aarch64 ABI supports NEON as default, so we should turn on NEON code for
aarch64. Also, libopus's NEON code doesn't support MSVC yet.
Differential Revision: https://phabricator.services.mozilla.com/D17332
--HG--
extra : moz-landing-system : lando
Caching text-shadows into texture cache was leading to rendering artifacts with
missing shadows. Switch to using the picture path for all picture blurs and
rely upon picture caching to reduce repetitive work.
Differential Revision: https://phabricator.services.mozilla.com/D17329
--HG--
extra : moz-landing-system : lando
This test checks that POST data can be submitted from both file and
moz-extension URIs to web content without the data being lost, or the
load being performed in the incorrect process.
Depends on D15612
Differential Revision: https://phabricator.services.mozilla.com/D15613
--HG--
extra : moz-landing-system : lando
This will only happen if the pref is enabled, and works through the existing
mechanism for process switching loads. It should enable POST data to be
preserved when performing a process switch, for example when submitting
a form on a file:// or moz-extension:// URI to a http:// URI.
Depends on D15611
Differential Revision: https://phabricator.services.mozilla.com/D15612
--HG--
extra : moz-landing-system : lando
This code largely skips the logic in load methods, and tries to simply get the
channel opened & connected to the correct listener ASAP, without breaking any
loading state.
Depends on D15610
Differential Revision: https://phabricator.services.mozilla.com/D15611
--HG--
extra : moz-landing-system : lando
With the old process selector service implementation, non-cached loads
would skip the call into the process selector.
This implementation piggybacks atop the existing 'redirectTo' mechanism.
This is unfortunately not the perfect system for catching these loads,
as it doesn't provide an opportunity for performing a final process
switch before redirecting to a non-http channel. In addition, it doesn't
provide indication that a redirect is going to happen, causing
potentially unnecessary process switches.
Not all places where 'redirectTo' is supported use this mechanism. This
process switching mechanism is only checked in situations after
http-on-examine-response.
Potential future changes include:
1. Moving these checks closer to the real 'OnStartRequest' call (e.g.
in ContinueProcessNormal + ContinueOnStartRequest3). This would mean
that loads other than the final load will not cause process swaps.
2. Adding a callback before a redirect is performed, passing in the new
channel, and allowing modifications to be made. This would allow
performing a process swap before redirecting to a non-http(s)
channel.
Depends on D15609
Differential Revision: https://phabricator.services.mozilla.com/D15610
--HG--
extra : moz-landing-system : lando
This is handy when performing process swaps, as it provides useful & important
information to parent-process callers.
Depends on D15608
Differential Revision: https://phabricator.services.mozilla.com/D15609
--HG--
extra : moz-landing-system : lando
This is needed because early in a content process's lifecycle, NeckoParent may
not have been created yet. This leads to issues when trying to redirect into a
fresh process which hasn't performed network loads yet. By sending the message
over PContent, we can be sure the APIs are available.
Differential Revision: https://phabricator.services.mozilla.com/D15608
--HG--
extra : moz-landing-system : lando
In the past we relied upon ViEEncoder::OnFrame to set the render time for
frames. With the branch 64 update, this code moved to
VideoStreamEncoder::OnFrame, and only sets the timestamp if it is greater than
the current time. This results in broken rtp timestamp estimates in the rtcp
sender report, which causes problems for Meet and possibly other services
that rewrite rtp timestamps based upon the sender report.
This patch makes VideoStreamEncoder::OnFrame always set the timestamp. In a
follow on bug, we'll move this behaviour to VideoConduit so we don't have to
maintain a local modification of the upstream code.
Differential Revision: https://phabricator.services.mozilla.com/D17413
--HG--
extra : moz-landing-system : lando
This cannot actually happen in the real world because this path is specific to
when the compositor process is also the parent process, and thus is not
actually IPC. However, the fuzzer can trigger this case.
Depends on D14587
Differential Revision: https://phabricator.services.mozilla.com/D14588
--HG--
extra : moz-landing-system : lando
HLSResourceCallbacksSupport::mDecoder is cleared on main thread too, so
the nullness check already ensures decoder methods won't be called after
shut down. In fact, for OnError() the lock is harmful because the task calls
MediaDecoder::NetworkError(), which triggers decoder shutdown and eventually
HLSResourceCallbacksSupport::Detach(), which tries to lock the mutex again
while the mutex is still locked.
Differential Revision: https://phabricator.services.mozilla.com/D16709
--HG--
extra : moz-landing-system : lando
VIEWPORT_MODE_DESKTOP *forces* the desktop mode viewport everywhere, whereas
VIEWPORT_MODE_MOBILE merely enables <meta> viewport support for pages that have
that tag defined, but still uses the desktop mode viewport for all other pages.
Differential Revision: https://phabricator.services.mozilla.com/D17159
--HG--
extra : moz-landing-system : lando
This patch is similar to Bug 1503420 Part 1.
nsIFrame::List()'s second argument should be a const char*, not an
integer. It'll crash if we pass 0 as const char*. Fix the bug by
omitting the argument because the default value of the argument is an
empty string.
Differential Revision: https://phabricator.services.mozilla.com/D17300
--HG--
extra : moz-landing-system : lando
There are two parts to this:
When the controller receives the first result and the context has an autofill value, then call a new input.autofill() method, which does the actual autofill in the input.
We shouldn't autofill when the user back spaces. Actually back spacing is just one example of deleting text at the end of the input; the user could select text and press delete, or use the delete-previous-word key shortcut, etc. So it's not correct to simply check whether the last keypress was a backspace and skip autofill then. We should copy the logic of the legacy autocomplete controller and check whether the new search string is a prefix of the old string. If so, then don't autofill. So I added that logic to UrlbarInput. I could have added similar logic to the controller or the context instead, but it makes the most sense being in the input since it's the input where the user is interacting with the text value.
Differential Revision: https://phabricator.services.mozilla.com/D17040
--HG--
extra : moz-landing-system : lando
