Bug 1624511 Comment 2 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 Oana Botisan, Desktop Release QA from comment #1)
> I am not able to reproduce this issue. Do you have some steps or do you know another way to crash a tab beside using about:crashcontent?

One thing I noticed is that when I had the bug the `crashed-restore-all-button = Restore All Crashed Tabs` string was shown rather than "Restore This Tab" but I don't know how to trigger that… when I reduce `dom.ipc.processCount` to two and then open a bunch of tabs and crash the one tab using https://github.com/luser/crashme-simple/blob/master/contentscript.js in the Browser Content Toolbox or using about:crashcontent, it only shows the crash page on the tab and the other tabs just restore from the session.

I just figured out STR with pinned tabs that existed in a previous session (which matches my original experience)… I don't know if the problem applies to non-pinned:

1. In a new profile set `dom.ipc.processCount` to `2` in about:config (just to make it easier to repro without opening so many tabs)
2. Load 8 tabs of https://example.com/
3. Pin the first 4 of those new tabs
4. Quit Firefox
5. Start Firefox with the same profile (the pinned tabs should be automatically restored, wait for that)
6. Click on a non-pinned example.com tab to load it
7. Load `about:crashcontent` in that tab

Expected result:
* I can restore the selected non-pinned tab
* Pinned tabs loaded in the same process can also be restored

Actual result:
* I can restore the selected non-pinned tab
* The pinned tabs have no URL or back/forward history and I have no option to restore the page so other session data (e.g. form field values) is also lost.

> The only thing I could reproduce was that if I crashed the whole tab, after Firefox is reopened the previous session can not be restored.

I guess that should be filed as a separate bug as that sounds bad too unless you are also talking about pinned tabs.
(In reply to Oana Botisan, Desktop Release QA from comment #1)
> I am not able to reproduce this issue. Do you have some steps or do you know another way to crash a tab beside using about:crashcontent?

One thing I noticed is that when I had the bug the `crashed-restore-all-button = Restore All Crashed Tabs` string was shown rather than "Restore This Tab" but I don't know how to trigger that… when I reduce `dom.ipc.processCount` to two and then open a bunch of tabs and crash the one tab using https://github.com/luser/crashme-simple/blob/master/contentscript.js in the Browser Content Toolbox or using about:crashcontent, it only shows the crash page on the tab and the other tabs just restore from the session.

I just figured out STR with pinned tabs that existed in a previous session (which matches my original experience)… I don't know if the problem applies to non-pinned:

1. In a new profile set `browser.startup.page` to 3 to enable session restore and `dom.ipc.processCount` to `2` in about:config (just to make it easier to repro without opening so many tabs)
2. Load 8 tabs of https://example.com/
3. Pin the first 4 of those new tabs
4. Quit Firefox
5. Start Firefox with the same profile (the pinned tabs should be automatically restored, wait for that)
6. Click on a non-pinned example.com tab to load it
7. Load `about:crashcontent` in that tab

Expected result:
* I can restore the selected non-pinned tab
* Pinned tabs loaded in the same process can also be restored

Actual result:
* I can restore the selected non-pinned tab
* The pinned tabs have no URL or back/forward history and I have no option to restore the page so other session data (e.g. form field values) is also lost.

> The only thing I could reproduce was that if I crashed the whole tab, after Firefox is reopened the previous session can not be restored.

I guess that should be filed as a separate bug as that sounds bad too unless you are also talking about pinned tabs.

Back to Bug 1624511 Comment 2