Bug 1724370 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to :kashav (he/him) from comment #9)
> We're collecting history changes correctly, but sometimes don't write the flushed data to disk soon enough on shutdown. 
> It's actually a little odd that this works perfectly with SHIP disabled.

So this problem actually exists without Fission too.

The reason the bug doesn't reproduce without SHIP is because ContentSessionStore uses [idle dispatch to push history updates to the parent]( https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/ContentSessionStore.jsm#438), which means history updates are generally (always?) pushed to Session Store well before the 15s interval timer expires. Then when Session Store receives the "quit-application" event (which is when it [closes the session file and saves final state to disk](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/SessionStore.jsm#944-950)), it has an up-to-date copy of session history entries.
(In reply to :kashav (he/him) from comment #9)
> We're collecting history changes correctly, but sometimes don't write the flushed data to disk soon enough on shutdown. 
> It's actually a little odd that this works perfectly with SHIP disabled.

So this problem actually exists without Fission too.

The reason the bug doesn't reproduce without SHIP is because ContentSessionStore uses [idle dispatch to push history updates to the parent]( https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/ContentSessionStore.jsm#438), which means history updates are generally (always?) pushed to Session Store well before the 15s interval timer expires. Then when Session Store receives the "quit-application" event (which is when it [closes the session file and saves final state to disk](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/SessionStore.jsm#944-950)), it has an up-to-date copy of session history data.
(In reply to :kashav (he/him) from comment #9)
> We're collecting history changes correctly, but sometimes don't write the flushed data to disk soon enough on shutdown. 
> It's actually a little odd that this works perfectly with SHIP disabled.

So this problem actually exists without Fission too.

The reason the bug doesn't reproduce without SHIP is because ContentSessionStore uses [idle dispatch to push history updates to the parent]( https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/ContentSessionStore.jsm#438), which means history updates are generally (always?) pushed to Session Store well before the 15s interval timer expires. Then when Session Store receives the "quit-application" event (which is when it [closes the session file and saves final state to disk](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/SessionStore.jsm#944-950)), it has an up-to-date copy of session history data, which is reflected in the data that is saved to disk and eventually restored.
(In reply to :kashav (he/him) from comment #9)
> We're collecting history changes correctly, but sometimes don't write the flushed data to disk soon enough on shutdown. 
> It's actually a little odd that this works perfectly with SHIP disabled.

So this problem actually exists without Fission too.

The reason the bug doesn't reproduce without SHIP is because ContentSessionStore uses [idle dispatch to push history updates to the parent]( https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/ContentSessionStore.jsm#438), which means history updates are generally (always?) pushed to Session Store well before the 15s interval timer expires. Then when Session Store receives the "quit-application" event (which is when it [closes the session file and saves final state to disk](https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/components/sessionstore/SessionStore.jsm#944-950)), it has an up-to-date copy of session history data.

Back to Bug 1724370 Comment 11