This action records the expanded paths in the scope panel.
While these paths are saved across pause/resume via lastExpandedScopes,
this particular action saves the data into `expandedScopes` which is specific to each paused/step location.
Differential Revision: https://phabricator.services.mozilla.com/D182552
This is slightly more complex than "scopes" actions.
Expressions aren't only evaluated on paused frames,
but also against the global scope of the target.
So that we have to accept having a null `selectedFrame`.
The main special case here is that the action will either have selectedFrame or thread attribute set.
Removing a few jest test as they are testing more mocks than actual code
and poorly replicate correct state regarding selected thread/frame.
Differential Revision: https://phabricator.services.mozilla.com/D182551
The current "thread context" is too loose. These actions are specific to the currently selected frame.
If we step to another frame, or select another frame in the call stack, or select another thread, we can cancel these async actions.
But instead of using the "context" pattern, only identify the "selectedFrame" attribute passed
and ensure it is still relevant.
Also correctly await for async actions from selectFrame.
Differential Revision: https://phabricator.services.mozilla.com/D182550
be -> 1b9ef9f4c2aa01457e0f4e01a9fbcce2c2b86b5e
cs -> 7098cc1ce44a0120a1d89ab03a7ec6fe57f9b0e6
fi -> db2ec8d2946041c8d241c2c50281d93c8f6479ab
it -> 1370df09391ceffbf3161ea1a798f7f067f54d11
skr -> 0e1ab8ca7b29427dd98877d876503d85d249a3b9
For some reason, on opensuse-tumbleweed, lsb_release is busted. It
exists, but fails. That situation is not handled by distro 1.4.0. That
was fixed in later versions. Upgrade to 1.8.0, which is the latest
version.
Differential Revision: https://phabricator.services.mozilla.com/D183463
This also fixes some incorrect inline documentation I found in some of our tests,
and fixes a case where we were showing the warning state for importing bookmarks
in browser_safari_passwords.js.
Differential Revision: https://phabricator.services.mozilla.com/D183506
Add a regression test for picture cache invalidation caused by scrolling
content with opacity-filtered stacking contexts. This test ensures that
picture cache tiles are not invalidated by scrolling when such
sub-pictures are present, which was the problem in bug 1836063.
Depends on D181664
Differential Revision: https://phabricator.services.mozilla.com/D182496
When processing a picture-cache-tile we find the lowest common ancestor
clip of each primitive in the cache-tile and set that as the clip root.
Not only does this save separately applying the clip to each primitive,
it also means we actually draw the parts of the cache tile which are out
of view. This means we don't have to redraw the cache tile every time
more of it scrolls in to view.
This mechanism doesn't work when we have Picture primitives inside a
picture-cache-tile, e.g. for applying a filter. Primitives in the
sub-Picture still had the viewport clip applied and so when the
sub-Picture intersected with the viewport edge we had to redraw the
cache tile on every scroll event.
This diff copies the common-ancestor-clip logic to sub-Picture
primitives. On pages with lots of opacity filtered areas (e.g.
w3schools.com) this eliminates unnecessary cache-tile invalidation and
massively improves scrolling performance on systems with a weak GPU.
Differential Revision: https://phabricator.services.mozilla.com/D181664
Automatically finds the bottom (earliest) commit of the fast-forward
stack in most cases and removes the need to specify the original
mozilla-central commit that elm was based on.
Differential Revision: https://phabricator.services.mozilla.com/D183050
We were using SpinEventLoopUntil to order the scans and the scan results but this seems to be overkill -- we should expect the main loop to process our tasks ery quickly. In addition, it's probably not desirable to wait before scheduling the next scan because a delay in main thread processing doesn't imply lack of movement so our update is still needed. Finally, we try to avoid SpinEventLoopUntil as much as possible.
Differential Revision: https://phabricator.services.mozilla.com/D183420
