Closed Bug 1073165 Opened 10 years ago Closed 10 years ago

[e10s] TypeError: this._historyListener is null when clicking crashed tabs that were never loaded.

Categories

(Firefox :: Session Restore, defect)

x86
All
defect
Not set
normal
Points:
3

Tracking

()

RESOLVED FIXED
Firefox 38
Iteration:
38.1 - 26 Jan
Tracking Status
e10s m5+ ---

People

(Reporter: mconley, Assigned: mconley)

Details

Attachments

(2 files)

STR: 1) In Preferences > General, configure Firefox to not load tabs until selected. 2) Open a number of tabs, and load some pages in them 3) Shut down the session 4) Reload Firefox but stay on the default selected tab 5) Find the plugin-container for the content process, and kill it - or somehow else reliably create a crash for the content process. 6) The selected tab should show the tab crashed interface. Open the Browser Console, and click on any of the background tabs that were never loaded / selected. ER: No error messages in the Browser Console. AR: The Browser Console shows: "TypeError: this._historyListener is null". According to ttaubert in bug 1070096 comment 16: "This happens when I select a tab that was pending and thus not fully restored yet when the content process crashed. Selecting it after the crash leads to sessionstore sending the "kick off restoration now" message but there is no info in the child anymore. "
Assignee: nobody → mconley
Note that I believe this will likely get fixed as part of bug 1065785.
This is console spew, and should be fixed by an m3. This is not high priority.
Flags: firefox-backlog+
Did this get fixed?
Flags: needinfo?(mconley)
Bah, no it did not. :/
Flags: needinfo?(mconley)
Points: --- → 3
Flags: qe-verify-
Status: NEW → ASSIGNED
SessionStore keeps track of tabs that still need to be lazily restored. When a tab crashes, we should clear that state so that SessionStore doesn't attempt to lazily restore a crashed browser.
Comment on attachment 8549157 [details] [diff] [review] Clear restore state for crashed tabs. r=? Hey Steven, does my usage of _resetLocalTabRestoringState make sense in this context?
Attachment #8549157 - Flags: review?(smacleod)
Comment on attachment 8549157 [details] [diff] [review] Clear restore state for crashed tabs. r=? Review of attachment 8549157 [details] [diff] [review]: ----------------------------------------------------------------- This looks fine to me. > Hey Steven, does my usage of _resetLocalTabRestoringState make sense in this > context? Yup, this is fine. As we discussed in IRC though, this is throwing away the fact that the tab was in the pending state when things crashed. That means when restore all crashed tabs lands it will either have to put everything in the pending state, or immediately restore them all (we won't be able to be smart and immediately restore live tabs / put the pending back as pending). Can you please add a short comment explaining that we're explicitly choosing to throw this information away here.
Attachment #8549157 - Flags: review?(smacleod) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
Iteration: --- → 38.1 - 26 Jan
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: