Right now, we do a content blocking check when we get the default
referrer policy. And this could happen even before the channel is
opened. This is undesirable for the ETP fission work since we need
information that is calculated when the channel is opened in the parent
to do a content blocking check.
And we find out that doing a content blocking check here is unnecessary
since the tracking state here is not decided yet since the channel
hasn't been opened. And we will update the referrer policy in the parent
once the tracking state is ready.
So, in this patch, we stop doing the content blocking checks when
getting the default referrer policy in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D70193
--HG--
extra : moz-landing-system : lando
This code is the same for both the new and the old version.
We use `patternAtom` because the new version will add the ability to search for an atom that is not identical to the pattern source (for example, a pattern containing a unicode escape).
Differential Revision: https://phabricator.services.mozilla.com/D69895
--HG--
extra : moz-landing-system : lando
This was an artifact of the previous world where the lazy and non-lazy
scripts were different instances. We also prefer the BCE does not directly
access the VM.
Differential Revision: https://phabricator.services.mozilla.com/D70108
--HG--
extra : moz-landing-system : lando
The function box is correctly initialized from the lazy BaseScript so we can
use the funbox instead of direct script access.
Differential Revision: https://phabricator.services.mozilla.com/D70107
--HG--
extra : moz-landing-system : lando
The previous code would mutate the inner lazy functions while generating
bytecode of their parents. This was difficult to keep track of, so instead
follow the approach used to update the enclosingScope. We save the info on
the funbox and then in FunctionBox::finish, we apply the update.
Differential Revision: https://phabricator.services.mozilla.com/D70106
--HG--
extra : moz-landing-system : lando
This brings the lazy TreatAsRunOnce flag in sync with the non-lazy one. Note
that although the flag is in-sync when we delazify, a lazy script with a lazy
parent will still be wrong.
Depends on D70287
Differential Revision: https://phabricator.services.mozilla.com/D70288
--HG--
extra : moz-landing-system : lando
This fixes a regression where immediately-invoked-function-expressions that
had a guessed-atom were no longer marked as run-once-lambdas.
Note: This can come up in some namespacing styles based on IIFEs such as:
var Mod = (function() {
function m1() {}
function m2() {}
return { m1, m2 };
})();
Differential Revision: https://phabricator.services.mozilla.com/D70287
--HG--
extra : moz-landing-system : lando
For building `macosx64-clang-tidy` with `linux64-clang-10` we need to build `cctools`
with `clang-10`.
Differential Revision: https://phabricator.services.mozilla.com/D70064
--HG--
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
WillDrawOpaqueNow tries to answer the question "if Draw is called on this image 'pretty soon' from now will it draw something opaque (so I know if I can cull stuff behind it for painting)".
But OrientedImage wants "is the frame I have right now opaque (so I can choose the right format for a surface I'm trying to draw the flipped image into)".
Bug 1260324 replaces imgIContainer::IsOpaque with WillDrawOpaquaNow, but it should have considered this case a bit more.
RasterImage::GetFrame already checks if the surface is finished before returning, and we have the format on the returned frame, so we don't need anything complicated here.
Differential Revision: https://phabricator.services.mozilla.com/D70303
--HG--
extra : moz-landing-system : lando
This reverts the patch landed in bug 1625857. As it turns out, the
driver version is less significant than the fact that it is a laptop
with dual GPUs. We should continue to give users with this driver
hardware acceleration for optimal performance.
Differential Revision: https://phabricator.services.mozilla.com/D70428
--HG--
extra : moz-landing-system : lando
In bug1571513, we added a mechanism of suspending/resuming media sink, and we should not recreate the media sink during the time of suspending media sink.
However, I found a case where we would create media sink during suspending period. That is via `UpdateOutputCaptured()`, and we should prevent it from creating media sink before we call `ResumeMediaSink()`.
Differential Revision: https://phabricator.services.mozilla.com/D70281
--HG--
extra : moz-landing-system : lando
When it refers computed value of style, it may flush pending notifications.
Therefore, they should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D70151
--HG--
extra : moz-landing-system : lando
Some methods take `StyleType` to work them with specified values or computed
values. This method hides `StyleType` into `CSSEditUtils` and splits the
public methods which took `StyleType` to 2 methods, one is for working with
specified values, the other is for working with computed values.
Additionally, this patch fixes some argument name and type.
Differential Revision: https://phabricator.services.mozilla.com/D70149
--HG--
extra : moz-landing-system : lando
The problem is that HeapPtr<> has a prebarrier in its destructor. This isn't necessary for weakly held values, and cause problems if the values have already been finalized. The patch also renames FinalizationRecordVectorObject to FinalizationRegistrationsObject to better describe its purpose.
Differential Revision: https://phabricator.services.mozilla.com/D70346
--HG--
extra : moz-landing-system : lando
Previously source-tests requiring a build had a "global" mapping of
platform to build type in kind.yml. But this made it confusing to
figure out how to add task-specific configuration. To simplify things,
make the configuration for the dependent platforms also go in the task
definition.
Differential Revision: https://phabricator.services.mozilla.com/D68636
--HG--
extra : moz-landing-system : lando
In rare cases, the random number generator can fail to initialize when
generating a v4 UUID, causing a panic and crash. This adds code to catch that
panic and return a nil (all zeros) UUID instead. Using a nil UUID seems better
from a user privacy perspective than failing to obfuscate the host address and
leaking it when it is expected to be hidden.
Longer term, we might want to switch over to using nsIUUIDGenerator, but that
would require changes to how the socket process is initialized.
Differential Revision: https://phabricator.services.mozilla.com/D70172
--HG--
extra : moz-landing-system : lando
Note that we intentionally don't move the SetDisplaySelection stuff to the
runnables. It would probably be safe enough, but it's not required and it makes
reasoning about this code harder.
Differential Revision: https://phabricator.services.mozilla.com/D70183
--HG--
extra : moz-landing-system : lando
This commit adds a new crate for bridging Rust Sync engines to Desktop,
and a `mozIBridgedSyncEngine` for accessing the bridge via JS.
Naturally, the bridge is called Golden Gate. 😊 For more information
on how to use it, please see `golden_gate/src/lib.rs`.
Other changes include:
* Ensuring the test Sync server uses UTF-8 for requests and responses.
* Renaming `mozISyncedBookmarksMirrorLogger` to `mozIServicesLogger`,
and moving it into the shared Sync interfaces.
The `BridgedEngine` trait lives in its own crate, called
`golden_gate_traits`, to make it easier to eventually move into a-s.
`Interruptee` and `Interrupted` already exist in a-s, and are
duplicated in this crate for now.
Differential Revision: https://phabricator.services.mozilla.com/D65268
--HG--
extra : moz-landing-system : lando
