1340872 - historychange kLastIndex usage vs. GroupedSHistory

Status: RESOLVED DUPLICATE of bug 1383876

(Firefox :: Session Restore, defect)

Description

[Jan Henning [:JanH]]

I'm not absolutely sure I'm following this code correctly, but this seems somewhat suspicious to me:

On some history change events, we're calling collect with fromIdx = kLastIndex (e.g. https://dxr.mozilla.org/mozilla-central/rev/698de2db1b16a5ef3c6a39f0f72885e69aee4022/browser/components/sessionstore/content/content-sessionStore.js#328), which, if I understand this correctly, signifies that we don't actually want to refresh any SHEntries and just want to update the current history index to its new position.

In that case, SessionHistory.jsm will discard all collected entries (https://dxr.mozilla.org/mozilla-central/rev/698de2db1b16a5ef3c6a39f0f72885e69aee4022/browser/components/sessionstore/SessionHistory.jsm#119) and just pass back the empty entries[] and the new index, which I guess end up here (https://dxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/TabStateCache.jsm#123), where we skip updating the cached entries if fromIdx == kLastIndex.

The problem I see however is that if we're collecting data from part of a GroupedSHistory, then SessionHistory.jsm will adjust the fromIdx by the respective globalIndexOffset, so the above check for kLastIndex no longer works.

Comment 1

[Jan Henning [:JanH]]

"Solved" by removing GroupedSHistory in bug 1383876.