The search field is now focused by the test code as part of intialization, which may cause the intermittent leak in bug 1507747 to surface.
Differential Revision: https://phabricator.services.mozilla.com/D17506
--HG--
extra : rebase_source : dfcc023ab23948869bacee14dfc1a00d51b24c0a
Use only ':' separator instead of 'menu:' to place titlebar buttons as the menu may not be always present.
Differential Revision: https://phabricator.services.mozilla.com/D17480
--HG--
extra : moz-landing-system : lando
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
