1716594 - Investigate if requestedIndex should be cleared when doing a replace load

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, task, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

This is related to bug 1697905.
We have no known bug reports about this, so need to try to write a testcase.
But it isn't clear yet, whether there is a bug.

Comment 1

[Chris Peterson [:cpeterson]]

This bug is a hard blocker for Fission MVP.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1716594, clear the requested index after replacing an entry, r=peterv

Looks like the code below does similar thing already for iframes, so this is adding InternalSetRequestedIndex
call only for the top level case.
This is based on the same assumptions as bug 1697905, but unfortunately testing this is still
super hard.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/94d021b67f6f
clear the requested index after replacing an entry, r=peterv

Comment 4

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/94d021b67f6f

Comment 5

[Cosmin Sabou [:CosminS]]

Backed out for causing Bug 1725458. It failed also on tier 1 jobs.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&tochange=7fb67d32d4914658ab6c84b1ae6bee3a34d8cf77&fromchange=2ad42f232d7ccef7417a2692640d342c5d9bb645&searchStr=Linux%2C18.04%2Cx64%2CWebRender%2Casan%2Copt%2CMochitests%2Cwith%2Cfission%2Cenabled%2Ctest-linux1804-64-asan-qr%2Fopt-mochitest-plain-fis-e10s%2C1&group_state=expanded&selectedTaskRun=eLy_gVYUR4CEkZElI9U9nQ.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=348329679&repo=mozilla-central

Backout link: https://hg.mozilla.org/integration/autoland/rev/a24828c47ac18ae4711b6bd94ca0feea71b98933

Comment 6

[Cosmin Sabou [:CosminS]]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/a24828c47ac1

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

the failure got me looking at this some more, and my current understanding is that we don't need this (this is basically handled already).