The previous version was trying to make index handling too generic.
But history loads need to update index to the requested index, not to the index of the current entry,
because the requested index was already passed to the child process when the
history load started. If there are several pending history loads, commit of the first one
will update the index based on requested index and send new index to the child.
When child side receives the index update, other pending history loads have been already
processed.
New loads can just clear the requested index, since the child side has
PendingSHistoryChange object to update the effective index and length to the
correct one and when parent side sends back the current index and length the
relevant PendingSHistoryChange object is removed.
With this version both
testing/web-platform/tests/old-tests/submission/Microsoft/history/history_000.htm
and
docshell/test/navigation/browser_test_simultaneous_normal_and_history_loads.js
pass now even on a debug build.
I think there might be a case for the issue happening also without SHIP, but
since it is way less asynchronous, triggering that issue is hard.
So the patch and test are for SHIP only.
Differential Revision: https://phabricator.services.mozilla.com/D116744
Surprisingly, previous changeset fix this. Following changeset is rather there for cleanups.
The fact that we instantiate a first JSWindowActor pair from frame-helper seems to do the trick.
The new code in frame-helper no longer conditionaly create the target for the top BC.
I also silent an exception happening in this test without fission.
Differential Revision: https://phabricator.services.mozilla.com/D117472
This only failed with devtools.target-switching.server.enabled=true as we emit top level target
from the Watcher only when this is enabled.
This is covered by browser_target_list_frames.js asserting a precise order in targets.
This test was failing with the pref set to true and should now pass in all 4 configurations.
(fission on/off + server target on/off)
Also try to destroy the top level target last, after all the remote iframes ones, but I'm not sure it is as important.
Note that we were trying to add the top level BC multiple times between code in utils.js vs worker-helper and frame-helper:getWatchingBrowsingContexts.
Differential Revision: https://phabricator.services.mozilla.com/D117471
Last year, we stopped vendoring Python packages that have native
code. Since we have only had pure-python packages since, the
Windows-specific qualifier (or excluder in the case of `!windows`)
hasn't been needed.
I don't foresee us needing it again, but if anything we can peel it
back from `hg` history if this assumption is incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D117468
The `mach_bootstrap:search_path()` implementation is out of
date compared to `virtualenv.py`.
Since `python2:`, `python3:` and `optional:` packages are no
longer valid virtualenv requirement actions, they can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D117707
On Windows, Python's temporary directories are placed in `%APPDATA%`.
Unfortunately, the failing tests want to assume that some "other"
path (as a subpath of a tempdir) won't be within any
`filter_args()` known top-level paths, which includes the user's home
dir.
The only reason that this assumption has passed in CI so far is due
to Windows case insensitivity: running locally had `~` evaluated
to `c:\Users\...`, while running in CI had it be `c:\users\...`.
Since the tempdir path started with `C:\Users`, `filter_args()`
would `<path omitted>` in CI but would `$HOME/...` locally.
By not basing the `other_path` on `tempdir`, we now consistently get the
same results across platforms.
Differential Revision: https://phabricator.services.mozilla.com/D117698
Not setting mIsSrcdocEntry causes us to drop srcdoc data and not set
INTERNAL_LOAD_FLAGS_IS_SRCDOC in FillLoadInfo for srcdoc restores.
Differential Revision: https://phabricator.services.mozilla.com/D117479
I think I botched some rebase and this bit sneaked in and neither of us noticed. It caused some previously passing tests to ended up as unexpected passes.
Differential Revision: https://phabricator.services.mozilla.com/D117642
Only a cosmetic change. There is a check during initialization that the constants match the sequential order so little room for getting it wrong.
Differential Revision: https://phabricator.services.mozilla.com/D117702
Also expose the information in the profiler HUD and rename some counters to make it more apparent when specific to the atlases as opposed to other textures mamanged by the texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D117695
Ensure that we only invalidate tiles if the surface scale changes
in low-quality pinch zoom mode, since it's irrelevant if the
compositor surface scale changes.
Differential Revision: https://phabricator.services.mozilla.com/D117727
This slightly changes panel initialization,
instead of updating the UI on opening as soon as the first top level target is available,
it will only update once the navigate resource fires.
So if we open the toolbox on a still loading document, it will update later, but only once
instead of twice.
Differential Revision: https://phabricator.services.mozilla.com/D117515
I'm not sure it is useful to hide ResourceCommand in the proxy layer.
It is better if all frontend uses Commands directly, having intermediate layer
make it harder to understand and debug.
Differential Revision: https://phabricator.services.mozilla.com/D117513
This help also remove the target watching as this was there
only to workaround the complexity/limitations of target actor's will-navigate.
`waitForSourceLoad` was resolving immediately on previous source,
already available before the reload.
Differential Revision: https://phabricator.services.mozilla.com/D117475