The fix let's ContentParent::RecvSynchronizeLayoutHistoryState update the layout history state.
Using an existing test to launch a subtest for this. Hopefully the description of the test helps with reviewing it.
(These BroadcastChannel based tests can be hard to follow.)
Differential Revision: https://phabricator.services.mozilla.com/D122376
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
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
This was somewhat convoluted to get to both reliably reproduce and not timeout
after the fixes were applied. The test can't run without Fission, as it
requires a process switch to occur on the navigation to/from
http://example.com.
Without part 2 of this patch stack, this test will crash after the process
switch.
Differential Revision: https://phabricator.services.mozilla.com/D110003
This was somewhat convoluted to get to both reliably reproduce and not timeout
after the fixes were applied. The test can't run without Fission, as it
requires a process switch to occur on the navigation to/from
http://example.com.
Without part 2 of this patch stack, this test will crash after the process
switch.
Differential Revision: https://phabricator.services.mozilla.com/D110003
Similarly to the old session history implementation, scroll position needs to be stored in HandleSameDocumentNavigation.
The relevant old implementation is couple of lines above the new code in nsDocShell.
Differential Revision: https://phabricator.services.mozilla.com/D109756
The old setup is a tad fragile since it relies on Stop to happen at a particular moment.
The name RefreshURIToQueue is just trying to be consistent with RefreshURIFromQueue
Differential Revision: https://phabricator.services.mozilla.com/D107930
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
