Closed Bug 1626397 Opened 5 years ago Closed 4 years ago

Restoring windows from a session does not respect whether or not Fission was enabled for each window

Categories

(Firefox :: Session Restore, defect, P3)

Product:
Firefox
Component:
Session Restore
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Project Flags:
Fission Milestone Future

People

(Reporter: annyG, Unassigned)

References

(Blocks 1 open bug)

Details

Steps to reproduce:

  1. Make sure you have fission enabled
  2. Open a new window, navigate to a site (window 1)
  3. Open a new Non-Fission window, navigate to a different site (window 2)
  4. Either try to update your browser or quit and agree to 'Close Tabs' when prompted.
  5. Start the browser again and click History -> Restore Session.

Expectations: we will have two windows, window 1 will be Fission enabled and window 2 will not be Fission enabled
Reality: both windows are fission enabled.

Summary: [Fission] Restoring windows in a session does → [Fission] Restoring windows from a session does not respect whether or not Fission was enabled
Component: DOM: Navigation → Session Restore
Product: Core → Firefox
Summary: [Fission] Restoring windows from a session does not respect whether or not Fission was enabled → [Fission] Restoring windows from a session does not respect whether or not Fission was enabled for each window

I can see why it would be useful for somebody to have this, but in my opinion we should leave it as-is to discourage people from keeping around non-Fission windows. eg if something is broken in Fission and we fix it, how long will it take before people using Fission actually start testing it if they'd already shuffled them off into permanent non-Fission windows?

I think this is an issue due to Fission being at the beginning of its dogfooding stage. If a user who is dogfooding Fission, opens a non-Fission window to do things that currently don't work with Fission, after the session is restored, they might expect that window to continue being non-Fission. Later, if the window that the user expected to be non-Fission crashes due to a Fission problem, information might be lost which might discourage the user from enabling Fission at all. I think this will be not necessary once we have finished dogfooding internally.

Perhaps we could make Fission enabled tabs more visually distinctive for this purpose for now to avoid such scenarios?

P2 M5b

We'd like to make Fission and non-Fission windows visually distinctive. Something like what we do with Private Browsing windows but using a Fission logo. Then we would not need to save tab's Fission state for session restore, which would be a lot gnarlier and could cause session store migration headaches.

e10s used to underline tab titles.

Fission Milestone: --- → M6b
Priority: -- → P2
Summary: [Fission] Restoring windows from a session does not respect whether or not Fission was enabled for each window → Restoring windows from a session does not respect whether or not Fission was enabled for each window

Tracking for Fission Nightly M6c. We don't plan to support Fission and non-Fission windows in the same browser session outside the Nightly channel, so there is debate on whether we should bother fixing this bug or not.

Severity: normal → S3
Fission Milestone: M6b → M6c
Priority: P2 → P3

This will be a Nightly-only feature and we can prioritize it later if more people request for it.

Fission Milestone: M6c → Future

We'll never ship the open non-fission window option by default so won't be fixing this.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.