Closed Bug 1647109 Opened 3 months ago Closed 3 months ago

can't navigate away from file:// URL

Categories

(Firefox :: Session Restore, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Firefox 80
Fission Milestone M6a
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- disabled
firefox77 --- unaffected
firefox78 --- disabled
firefox79 --- disabled
firefox80 --- fixed

People

(Reporter: heycam, Assigned: pbone)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Since enabling Fission, I ran into a problem today with navigation. In this one tab, I have a file:// URL page open. If I type an https:// URL into the address bar and press Enter, the spinner starts, and I see the hostname in the status bar at the bottom of the window, but the navigation never succeeds. In the browser console, I see this exception:

TypeError: can't access property "legacySHistory", history is null [SessionHistory.jsm:109:1]
    collect resource://gre/modules/sessionstore/SessionHistory.jsm:109
    collect resource://gre/modules/sessionstore/SessionHistory.jsm:39
    collectFrom resource:///modules/sessionstore/ContentSessionStore.jsm:200
    send resource:///modules/sessionstore/ContentSessionStore.jsm:469
    flush resource:///modules/sessionstore/ContentSessionStore.jsm:800
    receiveMessage resource:///modules/sessionstore/ContentSessionStore.jsm:616

If I try to visit a different file:// URL in that tab, it works. And navigating to an https:// URL from another tab that has a file:// URL document shown it works too, so something's gone wrong with this tab / process in particular.

Flags: needinfo?(alchen)
Blocks: fission
Component: DOM: Navigation → Session Restore
Product: Core → Firefox

I will check this problem today.

Flags: needinfo?(alchen)

I cannot reproduce this problem with fission enabled by

  1. open a "file:// URL" page
  2. type "an "https:// URL" into the address bar" and press Enter

I also take a look at the implementation before my rewriting.

[In the previous implementation]
First, history = webNavigation.sessionHistory;
https://searchfox.org/mozilla-central/rev/93ec4f0381e5a30076a465aec3d18c05f3c9b1d6/toolkit/modules/sessionstore/SessionHistory.jsm#84
Here we will have a similar problem.
We just access the legacySHistory without check if history is null or not.
https://searchfox.org/mozilla-central/rev/93ec4f0381e5a30076a465aec3d18c05f3c9b1d6/toolkit/modules/sessionstore/SessionHistory.jsm#89

We could check if history is null before accessing property "legacySHistory".
https://searchfox.org/mozilla-central/rev/46e3b1ce2cc120a188f6940b5c6eab6b24530e4f/toolkit/modules/sessionstore/SessionHistory.jsm#109

How about "data.requestedIndex"?
What should we do if there is no legacySHistory?
https://searchfox.org/mozilla-central/rev/46e3b1ce2cc120a188f6940b5c6eab6b24530e4f/toolkit/modules/sessionstore/SessionHistory.jsm#119

We don't handle this before.
So I suppose that it is not a big problem before.
Not sure how often do we meet this case when enabling fission?
It is the first time I saw this problem.

Flags: needinfo?(peterv)
Flags: needinfo?(mdeboer)
Fission Milestone: --- → ?
See Also: → 1647460

@ heycam, 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.

Fission Milestone: ? → M6a
Flags: needinfo?(cam)
Attached file my installed addons
Flags: needinfo?(cam)

While working on Bug 1647205 I hit the same exception as heycam, without fission but with preserve browsing contexts (some of the same code-paths).

I haven't tried with fission, but here's how I reproduce it:

  1. New profile
  2. Enable session restore
  3. Open two new tabs, they appear on the new tab home page.
  4. Close all other tabs.
  5. Close the browser
  6. Open the browser
    Repeat steps 3-6 once more (not sure how necessary this is).
  7. Navigate the first one to wikipedia.com (you can click the link on the new tab page)
  8. Switch to the second one, it restores now.
  9. Attempt to navigate it, it doesn't navigate and you get the exception above.

file:// -> http:// is a remoteness change, so is the about:newtab -> http:// So I guess they're hitting the same code path. heycam, can you remember if session restore may have been involved in your problem?

Flags: needinfo?(cam)
See Also: → 1647205

(In reply to Paul Bone [:pbone] from comment #6)

heycam, can you remember if session restore may have been involved in your problem?

I don't recall if those tabs were session restored at some point (I tend to update only once a week or two), but it's certainly possible.

Flags: needinfo?(cam)
See Also: → 1648760

I tried my STR above with mozregression (not this is without fission) and found Bug 1550571 in that regression range also.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fab7c4f54054ceb06504c7ddac380858e2521fc4&tochange=10ad7868f3ca27cb90db9bd1d392ff4d7852a0cd

Unless there are multiple bugs with the same symptom I'd say this is the culprit.

Regressed by: 1550571
Assignee: nobody → pbone
Status: NEW → ASSIGNED
Priority: -- → P1
Depends on: 1649125

(In reply to Paul Bone [:pbone] from comment #6)

  1. New profile
  2. Enable session restore
  3. Open two new tabs, they appear on the new tab home page.
  4. Close all other tabs.
  5. Close the browser
  6. Open the browser
    Repeat steps 3-6 once more (not sure how necessary this is).
  7. Navigate the first one to wikipedia.com (you can click the link on the new tab page)
  8. Switch to the second one, it restores now.
  9. Attempt to navigate it, it doesn't navigate and you get the exception above.

These STR don't work for me.

See Also: → 1650537

BrowsingContext::GetChildSessionHistory will only return mChildSessionHistory if it has been set as being in this process, with SetIsInProcess. This is usually set if the BrowsingContext has a docshell. But not by the CreateChildSHistory() method. This method is used by DidSet(FieldIndex<IDX_HasSessionHistory>, bool aOldValue), which I think is used to synchronise properties between BCs in different processes. I think what's happening is that some synchronisation is causing DidSet to call CreateChildSHistory() which makes a new ChildSHistory object and does not set that it is in this process. I'm not yet sure why this property is set elsewhere and then synchronised, but maybe instead CreateChildSHIstory() should just call SetIsInProcess()? I'm testing this now.

Attachment #9161599 - Attachment description: Bug 1647109 - SetIsInProcess when the browsing context has a docshell r=kmag → Bug 1647109 - Set the child history as in process when the BC is in process r=kmag
Blocks: 1650979
Flags: needinfo?(peterv)
Flags: needinfo?(mdeboer)
Pushed by pbone@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4f83cf116474
Set the child history as in process when the BC is in process r=kmag
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 80
Duplicate of this bug: 1648760
Blocks: 1653482
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.