nsDisplayTableBackgroundColor inherits from nsDisplayBackgroundColor,
and both display item types are mapped to background_color property.
However, nsDisplayTableBackgroundColor is not animated on the
compositor, so we shouldn't add animations for TYPE_TABLE_BACKRGOUND_COLOR.
It seems the test case has a weird timeout in Android test-verify-opt. I
checked the live.log and the tests are passed, but got a final time-out.
It is not related to our change because this still happens if we skip
the test, and I saw that other intermittent bugs have the same issue.
Differential Revision: https://phabricator.services.mozilla.com/D24780
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
With this change, the use of SlashIsInvalid at the top of
GeneralParser<>::classMember obliges us to use the same modifier when getting
the same token later (in both classMember and propertyName).
Differential Revision: https://phabricator.services.mozilla.com/D26928
--HG--
extra : moz-landing-system : lando
On Android, update mozilla gtest logging so that logging appears in the Android logcat.
Also, when MOZ_GTEST_LOG_PATH is defined in the environment, create the named file
and direct logging to that file. Android gtest will use this to collect gtest logging from
the device and copy it to the test log.
Differential Revision: https://phabricator.services.mozilla.com/D26610
--HG--
extra : moz-landing-system : lando
Previously this functionality created a CryptoTask to do this work, but that
would cause a new thread to be created for each list of intermediates. This was
slow both because of all of the threads and because they could be scheduled
while other work was happening. Moving these tasks to the low-priority event
queue for threads in the certificate verification thread pool means no new
threads are created and the work only happens when these threads are idle
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D26630
--HG--
extra : moz-landing-system : lando
We don't need an additional array just for byte reordering, replace
it with in-place processing.
Testcase are modified because the LookupCacheV4::Build API now clears the
input parameter.
Differential Revision: https://phabricator.services.mozilla.com/D26861
--HG--
extra : moz-landing-system : lando
Here is the flow how prefixes are handled during an V4 update:
1. Prefixes are received from Safe Browsing update, stored in ProtocolBuffer
2. Copy the prefixes from ProtocolBuffer to TableUpdate structure
3. Prefixes in TableUpdate are merged with local prefixes (stored in LookupCacheV4)
4. Merged prefixes are processes by PrefixSet to generate the in-memory prefix
set data structure (MakePrefixSet).
In this patch, we free the prefixes stored in TableUpdate right after step3.
This reduces the peak memory used during an update (peak happens in step 4).
Differential Revision: https://phabricator.services.mozilla.com/D26860
--HG--
extra : moz-landing-system : lando
(more a feedback request than review request at this stage)
Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.
Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?
Differential Revision: https://phabricator.services.mozilla.com/D26211
--HG--
extra : moz-landing-system : lando
apilint 0.1.9 fixes a bug that was causing us to miss some annotation lints.
This commit fixes all of them before we can upgrade.
Depends On D26028
Differential Revision: https://phabricator.services.mozilla.com/D26029
--HG--
extra : moz-landing-system : lando
As we have successfully rolled out the feature via Normandy in 66, we should turn the feature on in >= 67 to not have to rely on Normandy going forward any more.
Differential Revision: https://phabricator.services.mozilla.com/D26713
--HG--
extra : moz-landing-system : lando
YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
Bug 1500504 added a version check for the SDK, but it only does the
check if --with-macos-sdk is used. We should also check the version when
using the default SDK.
Note that this means we now set MACOS_SDK_DIR to be the default SDK even
if it wasn't set explicitly from --with-macos-sdk
Differential Revision: https://phabricator.services.mozilla.com/D17727
--HG--
extra : moz-landing-system : lando
This has some fun wins
- colored prompt
- multiline textarea
- default value for log points
Differential Revision: https://phabricator.services.mozilla.com/D26585
--HG--
extra : moz-landing-system : lando
Since it wasn't reliable, we remove the topWindowPrincipal in favor of WindowGlobalParent->DocumentPrincipal()
Differential Revision: https://phabricator.services.mozilla.com/D24897
--HG--
extra : moz-landing-system : lando
The principal we got from the child process was always a null principal, which was wrong.
This approach seems to give you the actual principal of the current document.
Differential Revision: https://phabricator.services.mozilla.com/D24895
--HG--
extra : moz-landing-system : lando
ClientTiledPaintedLayer::GetTransformToAncestorsParentLayer calculates
the transform from the layer to its display port ancestor's
parent. This transform is then applied to the calculated display
port.
However, if the display port ancestor participates in a preserve-3d
context then the scroll offset will not be included in the that
layer's transform, it will instead be on the root layer of the
preserve-3d context. This was causing the critical display port to
remain still as the contents of a perspective transform were scrolled,
resulting in content being permanently painted in low-precision as the
page was scrolled down.
Instead, if the display port ancestor participates in a 3d context, we
must find the root of that 3d context then calculate the transform to
*that* layer's parent.
Differential Revision: https://phabricator.services.mozilla.com/D26821
--HG--
extra : moz-landing-system : lando
