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)
Tracking
()
Tracking | Status | |
---|---|---|
e10s | m5+ | --- |
People
(Reporter: mconley, Assigned: mconley)
Details
Attachments
(2 files)
(deleted),
patch
|
smacleod
:
review+
|
Details | Diff | Splinter Review |
(deleted),
application/zip
|
Details |
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. "
Updated•10 years ago
|
Assignee: nobody → mconley
Assignee | ||
Comment 1•10 years ago
|
||
Note that I believe this will likely get fixed as part of bug 1065785.
Updated•10 years ago
|
Comment 2•10 years ago
|
||
This is console spew, and should be fixed by an m3. This is not high priority.
Updated•10 years ago
|
Flags: firefox-backlog+
Updated•10 years ago
|
Points: --- → 3
Flags: qe-verify-
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•10 years ago
|
||
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.
Assignee | ||
Comment 6•10 years ago
|
||
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 7•10 years ago
|
||
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+
Assignee | ||
Comment 8•10 years ago
|
||
Done - thanks!
remote: https://hg.mozilla.org/integration/fx-team/rev/3fa318009bce
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
Updated•10 years ago
|
Iteration: --- → 38.1 - 26 Jan
Assignee | ||
Comment 10•10 years ago
|
||
bugnotes |
You need to log in
before you can comment on or make changes to this bug.
Description
•