Open
Bug 1257417
Opened 9 years ago
Updated 3 years ago
[e10s] Pinned tabs aren't loaded when the content process crashes
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
NEW
People
(Reporter: reuben, Unassigned)
References
Details
STR:
1) Content process crashes
2) I click to report the crash and restore the tab
Results:
Pinned tabs are unloaded.
Expected results:
Pinned tabs should reload when the content process is restored.
Comment 1•9 years ago
|
||
Can you check bug 1104274 comment 5?
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #5)
> That tells me that something screwed up with the takedown of those browser
> tabs when the content process crashed - so it's not surprising that your
> session got all screwed up. :/
>
> If you see this again, can you please open the Browser Console to see if
> there's anything strange in there that might indicate what went wrong during
> the crash handling?
Flags: needinfo?(reuben.bmo)
See Also: → 1104274
Comment 2•9 years ago
|
||
Hmm, actually, this is like bug 1254569 instead - couldn't find that initially because it didn't have "e10s" in the summary.
What confuses me is that that was duped to a bug 1227630, which is about the favicons disappearing - but I think the point is that pinned tabs should autorestore, because they're pinned tabs, which might be a separate issue? Mike?
Blocks: 1227630
Flags: needinfo?(reuben.bmo) → needinfo?(mconley)
> Expected results:
>
> Pinned tabs should reload when the content process is restored.
This is not the expected result. See bug 1256280 comment 9 (other comments as well)
Depends on: 1256280
Reporter | ||
Comment 4•9 years ago
|
||
(In reply to arni2033 from comment #3)
> > Expected results:
> >
> > Pinned tabs should reload when the content process is restored.
>
> This is not the expected result. See bug 1256280 comment 9 (other comments
> as well)
Sure, the situation right now with a single content process is not optimal, but IMO not restoring them is a regression from the non-e10s behavior. My pinned tabs are pinned precisely because I want them to be loaded at all times.
Comment 5•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #2)
> Hmm, actually, this is like bug 1254569 instead - couldn't find that
> initially because it didn't have "e10s" in the summary.
>
> What confuses me is that that was duped to a bug 1227630, which is about the
> favicons disappearing - but I think the point is that pinned tabs should
> autorestore, because they're pinned tabs, which might be a separate issue?
> Mike?
Yeah agreed - I think we made a mistake while triaging and thought this was the favicon bug. I'll undupe it, redupe it to this bug, and get this one triaged.
Flags: needinfo?(mconley)
Updated•9 years ago
|
tracking-e10s:
--- → ?
(In reply to Reuben Morais [:reuben] from comment #4)
> Sure, the situation right now with a single content process is not optimal, but IMO not
> restoring them is a regression from the non-e10s behavior. My pinned tabs are pinned precisely
> because I want them to be loaded at all times.
I thought that what you're requesting is automatic restoration of pinned tabs... My apologies :(
I only give a feedback about what's working wrong (IMO), and the obviously wrong things here are:
1) auto-reloading of pinned tabs _before_ user clicks "Restore Tab" (explained in bug 1256280)
2) reloading of pinned tabs even for users with prev "restore_pinned_tabs_on_demand" set to true
No longer depends on: 1256280
![]() |
||
Updated•9 years ago
|
Blocks: e10s-multi
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•