Open Bug 1591942 Opened 4 months ago Updated 4 months ago

Run browser_mozprotocol.js test with Fission enabled

Categories

(Firefox :: General, task, P3)

task

Tracking

()

Fission Milestone Future

People

(Reporter: mconley, Unassigned)

References

(Blocks 1 open bug)

Details

With Fission enabled, browsing to moz://a in the URL bar results in an infinite process flipping loop.

It's supposed to redirect us to the Manifesto: https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/toolkit/components/mozprotocol/MozProtocolHandler.jsm#17 - or to the Mozilla Canada community page if using moz://eh.

Once this is fixed, we should be able to get browser_mozprotocol.js working with Fission enabled.

Hey Neha, I filed this bug so we could hook up something to row 620 of the Fission Mochitest tracking spreadsheet, but I'm relatively certain this is not an M4 thing we need to fix - we've got more important fish to fry than an easter egg. Should I go ahead and put this in M5 or Future?

Fission Milestone: --- → ?
Flags: needinfo?(nkochar)
Priority: -- → P3

Mike, this seems to be getting fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1588412#c3 .

Flags: needinfo?(nkochar)

Oooh, amazing! Thanks. :)

Depends on: 1588412
Summary: Update moz:// protocol to work with Fission → Run browser_mozprotocol.js test with Fission enabled

I don't think bug 1588412 will fix this unfortunately.

I haven't debugged this fully, but if we're getting into a process switching loop, then I suspect that we're trying to make the process decision in multiple places, and coming up with different results.

I think what's happening that is DocumentChannelParent is calling into http-on-may-change process, which picks a process to use, and gets the 'real' URI from the actual channel (which I think will be the resolved http manifesto UR).

Then we setup a new process/docshell, and attempt to load there and then hit this process check - https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/docshell/base/nsDocShell.cpp#9253

That one is just using the URI from the DocShellLoadState, and could likely be the moz:// one. I suspect that'll then come up with a different answer, and we'll attempt to restart the load in a different process.

The long term fix is to get rid of the old process switching checks, and only ever use DocumentChannelParent. In the short term, maybe we could check for aLoadState->GetPendingRedirectedChannel() to detect when the current load is one that has been switched to us, and not check again.

Flags: needinfo?(matt.woodrow)
Fission Milestone: ? → Future
You need to log in before you can comment on or make changes to this bug.