Closed Bug 1647460 Opened 4 years ago Closed 4 years ago

Session history sometimes broken under Fission after session restore or un-closing a tab

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

RESOLVED FIXED
Fission Milestone M6a

People

(Reporter: jld, Assigned: peterv)

References

Details

Sometimes, when a tab is loaded after session restore with Fission enabled — or, one time, when I un-closed it (the cmd/ctrl-shift-T keybind) — history doesn't work. The pref fission.sessionHistoryInParent is false (and in general I didn't touch any Fission prefs other than autostart.)

Specifically, history.length throws an exception, identified as type Exception, with a name property of "NS_ERROR_FAILURE" and no other identifying info besides the stack trace. This seems to cause a lot of breakage (e.g., Twitter completely fails, Bugzilla can't submit new bugs, a shopping site can't show product images) because of script that accesses it during initialization.

Additionally, the browser chrome has the back/forward buttons grayed out, the location bar doesn't change if the page is navigated, and reloading returns to the original page.

I can't reliably reproduce it, but I can try to debug it more the next time it shows up if I know what to look for.

It looks like this is a similar issue to bug 1647109. This is being caused by a content process not having a session history object anymore: https://searchfox.org/mozilla-central/rev/3d39d3b7dd1b2be30692d4541ea681614e34c786/dom/base/nsHistory.cpp#59-65

It seems like we're somehow ending up in a situation where we have a tab with no session history in it.

Peter, could you take a look at this?

Fission Milestone: --- → ?
Flags: needinfo?(peterv)
Component: DOM: Content Processes → DOM: Navigation

@ Jed, can you please share which extensions you have installed? Copy/pasting the list from about:support is the easiest way to share. Nika suspects this bug might be related to container tabs.

Tracking for Fission M6a Nightly because many people are reporting this problem. kmag sees this problem and says it seems to be more likely with file:// URLs. Possibly related to an extension using a request listener?

See also session restore bug 1647109. Alphan couldn't repro bug 1647109. I will ask heycam for his list of extensions in that bug.

Assigning to peterv

Assignee: nobody → peterv
Fission Milestone: ? → M6a
Flags: needinfo?(jld)
See Also: → 1626362
See Also: 16263621647109

Taking the intersection of the two profiles where I've seen this, and removing built-in search engines:

Firefox Multi-Account Containers        6.2.5       @testpilot-containers
HTTPS Everywhere        2020.5.20           https-everywhere@eff.org
Stylus  1.5.11      {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}
Switch Container Plus   0.19        {d5ac33ed-723c-402b-b17c-e7bbb0d3a80d}
Tab Counter     0.4.1       tab-counter@daawesomep.addons.mozilla.org
Temporary Containers    1.8         {c607c8df-14a7-4f28-894f-29e8722976af}

Also one of them has uMatrix and the other has uBlock Origin, both of which filter requests (and share an author).

The tabs where I see this aren't in containers.

Flags: needinfo?(jld)

Has this been resolved since Bug 1647109 is now fixed? is it still recurring.

ni? me for the question in comment #4

Flags: needinfo?(jld)

I haven't seen this since I updated to a build after bug 1647109 landed, so I think it's fixed.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(peterv)
Flags: needinfo?(jld)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.