* The existing code to detect if an image is dirty fails in some
cases. For external images, they were not being added to the
list of dirty images when update was called. Further, since
the dirty image keys hash set was cleared each frame, it was
possible for an image to become dirty, but this detection to be
missed if it is not queried until a subsequent frame (due to
it being off-screen.
Instead, each image template has a generation identifier that
is incremented whenever an image template is updated. The picture
caching code stores the generation of the image key when it was
rasterized, and compares that to the current image key generation
when comparing dependencies. This fixes both cases above.
* Remove the is_cacheable logic that was previously used to
invalidate picture cache tiles for external images. This would
result in picture cache images that intersect with videos being
invalidated every frame unconditionally. However, this code path
is no longer required, due to the change above. By relying on
the true image dirty check, we can skip invalidating tiles
affected by video if the video frame has not advanced (e.g. it
is paused, or advancing at a lower frame rate than we are
currently compositing at).
Differential Revision: https://phabricator.services.mozilla.com/D55061
--HG--
extra : source : 93ccc760c4dd69f63d6ac171ace357b0dd31412a
Summary of changes:
* Copy aboutDialog-appUpdater.js to a new aboutDialog-appUpdater-legacy.js file
* Update aboutDialog-appUpdater.js: Rewrite it to use the new AppUpdater.jsm when the `browser.aboutDialogNewAppUpdater` pref is true, and load aboutDialog-appUpdater-legacy.js otherwise
* In toolkit/mozapps/update/tests/browser, add new browser.legacy.ini and browser.legacy.bits.ini files that do not set `browser.aboutDialogNewAppUpdater` to true, so that the old implementation is still tested
* Update browser.ini and browser.bits.ini files to set `browser.aboutDialogNewAppUpdater` to true so that the new implementation is tested
If all this is OK, I'll file another bug for removing the legacy stuff once we merge.
Differential Revision: https://phabricator.services.mozilla.com/D54837
--HG--
rename : browser/base/content/aboutDialog-appUpdater.js => browser/base/content/aboutDialog-appUpdater-legacy.js
rename : toolkit/mozapps/update/tests/browser/browser.bits.ini => toolkit/mozapps/update/tests/browser/browser.legacy.bits.ini
rename : toolkit/mozapps/update/tests/browser/browser.ini => toolkit/mozapps/update/tests/browser/browser.legacy.ini
extra : moz-landing-system : lando
Make `ChangesContextMenu` directly extend `Menu` instead of wrapping it so external objects and tests can listen to its events.
Reduce `ChangesContextMenu`'s knowledge about the outside world (like `ChangesView`) by providing it in the constructor with the callbacks necessary for each context menu item.
Differential Revision: https://phabricator.services.mozilla.com/D55448
--HG--
extra : moz-landing-system : lando
We need to ensure we have a unique inner so that ruleLists and such have the
right pointer identity (we could do better, really, but it's harder).
But as long as the CSSOM hasn't modified them there should be no reason not to
use the cache. We can do a deep clone synchronously instead of refetching /
reparsing.
This is important because, as of right now, just using the inspector makes the
stylesheets unique, which is unfortunate.
We'll still have the modified rule bit for sheets with @import, because our
notification system for @import is silly, and on parents of imported sheets.
Fixing those are future improvements, but I see no reason not to land this.
Differential Revision: https://phabricator.services.mozilla.com/D55163
--HG--
extra : moz-landing-system : lando
Using an array is much better to reason about than a manually linked list, and
allows us to preserve @import order.
Added a test for a bug that we happened not to have, but that it's not covered
by existing WPT tests.
Differential Revision: https://phabricator.services.mozilla.com/D55565
--HG--
extra : moz-landing-system : lando
Test is hopefully self-explanatory. The children setup here is a bit bogus as
noted here and other comments, will file a followup to clean it up.
Differential Revision: https://phabricator.services.mozilla.com/D55550
--HG--
extra : moz-landing-system : lando
Rather than clearing results on tab switch or deactivate, let's keep them, and
clean them on input change. On reopening the view run the query again, so results
are up to date and autofill works, but flickering is reduced.
Differential Revision: https://phabricator.services.mozilla.com/D52645
--HG--
extra : moz-landing-system : lando
Move the relazification decisions to JSScript since the check is made after
delazification happens. The JSScript::isRelazifiable check inspects
characteristics of the script itself, while JSScript::canRelazify includes
additional checks for runtime conditions outside the script.
Depends on D55362
Differential Revision: https://phabricator.services.mozilla.com/D55390
--HG--
extra : source : 14f33b78f0eb5e32fd3e9c116f21a23ab7221f26
extra : amend_source : b589a2468c961591d1ada333857118e9e3a26e64
Now that both LazyScript and JSScript have the same pointer field, we can
move to the BaseScript class. The inner-function pointers in the gcthings
array will have the same meaning for both LazyScript and JSScript, but the
other members of gcthings may have different interpretations.
This adds poisoning of the PrivateScriptData in the LazyScript case for
consistency.
Depends on D55361
Differential Revision: https://phabricator.services.mozilla.com/D55362
--HG--
extra : source : 617ce539db705444da7589ecba02e4060d825a2e
Reorder the classes in JSScript.h so that we can use PrivateScriptData from
within BaseScript.
Depends on D55360
Differential Revision: https://phabricator.services.mozilla.com/D55361
--HG--
extra : source : 47f84263339e71dcca4b8cf03179f5722b7503fd
It it straight-foward for users of LazyScriptData to support a single array
for closedOverBindings and innerFunctions. As a result, we can use
PrivateScriptData as the implementation and eliminate the LazyScriptData type
altogether.
Depends on D55035
Differential Revision: https://phabricator.services.mozilla.com/D55360
--HG--
extra : source : 07471e96b2d8fdec534ee3c03432d1fe21095599
Unify the JSScript::warmUpData_ and LazyScript::enclosingLazyScriptOrScope_
fields into BaseScript. As a script progresses from lazy up to being JIT-ed
it the type stored in this field will change. If a script is in a compiled
state, the enclosingLazyScriptOrScope_ value can always be reconstructed
during relazification.
Depends on D55034
Differential Revision: https://phabricator.services.mozilla.com/D55035
--HG--
extra : source : 5163670bfede45831e1d2eb246eceeaa774d2631
Allow storing manually-barriered GC pointers in ScriptWarmUpData. This
updates the 'trace' method as needed. When switching types, the user must
first 'clear' the old type and then 'init' the new type. We continue to use
WarmUpCount(0) as the default safe state.
Depends on D55033
Differential Revision: https://phabricator.services.mozilla.com/D55034
--HG--
extra : source : 5ea098cc9ef02f4391d2ed8c8f0a64625a9042fa
Prepare to move the warmUpData field to BaseScript by first moving the type
definition earlier in the file.
Differential Revision: https://phabricator.services.mozilla.com/D55033
--HG--
extra : source : 42ca239ee6a65d3f28f1990da62db7efe2c19bd8
This adds the shell option for all the FinalizationGroup tests and updates the test262 update script. We still need to run the update script so that the tests do feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D55121
--HG--
extra : moz-landing-system : lando
The patch adds a new option that can be used from jstests.list to pass additional shell command line options. With feature detection (skip-if) this allows us to have tests running on infra for experimental features that are not yet supported in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D54316
--HG--
extra : moz-landing-system : lando
There are two places using DBService during a page load at startup:
1. nsChannelClassifier::Start, used by Phishing Protection
2. AsyncChannelClassifier::CheckChannel, used by Tracking Protection
Tracking protection checks happen before establishing a network connection, so it happens
prior to phishing protection checkes. When we load a page at
startup, ::CheckChannel API is called, but DBService is not yet created.
This patch fixes this issue by creating a DBService instance when
::GetWorker API is called without a DBService instance.
Differential Revision: https://phabricator.services.mozilla.com/D55248
--HG--
extra : moz-landing-system : lando
`StoreBuffer::putSlot` when called with a nursery object as its `obj` parameter
is a no-op, because `StoreBuffer::put` is a no-op when `Edge::maybeInRememberedSet`
return false, which, in the case of `SlotsEdge`, happens when `SlotsEdge::object()`
is in the nursery. This enables us to skip the linear traversal of the elements
array in `elementsRangeWriteBarrierPost` when the current object is in the nursery.
Differential Revision: https://phabricator.services.mozilla.com/D55420
--HG--
extra : moz-landing-system : lando
Move the relazification decisions to JSScript since the check is made after
delazification happens. The JSScript::isRelazifiable check inspects
characteristics of the script itself, while JSScript::canRelazify includes
additional checks for runtime conditions outside the script.
Depends on D55362
Differential Revision: https://phabricator.services.mozilla.com/D55390
--HG--
extra : moz-landing-system : lando
Now that both LazyScript and JSScript have the same pointer field, we can
move to the BaseScript class. The inner-function pointers in the gcthings
array will have the same meaning for both LazyScript and JSScript, but the
other members of gcthings may have different interpretations.
This adds poisoning of the PrivateScriptData in the LazyScript case for
consistency.
Depends on D55361
Differential Revision: https://phabricator.services.mozilla.com/D55362
--HG--
extra : moz-landing-system : lando
Reorder the classes in JSScript.h so that we can use PrivateScriptData from
within BaseScript.
Depends on D55360
Differential Revision: https://phabricator.services.mozilla.com/D55361
--HG--
extra : moz-landing-system : lando
Mihai Alexandru Michis
David Burns
Michael Ratcliffe
shindli
Simon Giesecke
Mark Banner
Glenn Watson
Razvan Caliman
Henri Sivonen
Thomas Nguyen
Edgar Chen
Drew Willcoxon
Emilio Cobos Álvarez
Mike de Boer
Marco Bonardo
Ted Campbell
Coroiu Cristina
Noemi Erli
Jon Coppeard
ffxbld
Jonathan Watt
Dimi Lee
André Bargull