Closed Bug 1597154 Opened 5 years ago Closed 5 years ago

[Fission] URLs that require external helper apps and/or prompting the user reload content processes forever

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla76
Fission Milestone M5
Tracking Status
firefox76 --- fixed

People

(Reporter: Gijs, Assigned: pbone)

References

(Depends on 1 open bug)

Details

Attachments

(5 files, 4 obsolete files)

I'm running into this in the automated test I'm adding in bug 1496380. "Manual" STR:

  1. open the browser with fission enabled
  2. load data:text/html,<a href="fooprotocol:test">Click me</a>
  3. click the link

ER:
an error page ("The address wasn't understood"), or a prompt to ask what app we should open the protocol with (try substituting fooprotocol with itunes on a machine that has itunes installed, or a zoom link on a machine that has zoom installed).

AR:
the tab spins forever (in the background, it is basically spawning and killing content processes with the null principal as quickly as it can manage)

What's happening here is the same as in bug 1586148. That is, my fix specifically checked for web handler apps, but didn't deal with the general case of not being able to handle protocols within the browser, and it turns out that case has the same problem...

Moving to backlog.

Priority: -- → P3

I think what's happening is that ShouldLoadURI being called from the docshell, and onMayChangeProcess being called by DocumentChannel are disagreeing on what process we should do the load in.

ShouldLoadURI causes us to cancel the current load, switch process and try again. onMayChangeProcess redirects the current load into a new process.

It looks like we redirect the load into a new process, and then ShouldLoadURI rejects it and starts it in another new process. Repeat.

We should probably do a few things:

  • Not check ShouldLoadURI when we're picking up a redirected load (ResumeRedirectedLoad calls into InternalLoad in that case), since the decision has already been made.
  • Not check ShouldLoadURI for protocols that DocumentChannel makes a decision for (we have some checks in E10SUtils, but they're a subset of DC's protocols).
Assignee: nobody → pbone
Status: NEW → ASSIGNED

I guess adding logging to the two decision making paths in E10SUtils to understand why we come up with different results would be good too.

Tracking for Fission dogfooding (M5)

Fission Milestone: ? → M5

(In reply to Matt Woodrow (:mattwoodrow) from comment #2)

I think what's happening is that ShouldLoadURI being called from the docshell, and onMayChangeProcess being called by DocumentChannel are disagreeing on what process we should do the load in.

ShouldLoadURI causes us to cancel the current load, switch process and try again. onMayChangeProcess redirects the current load into a new process.

I had some debugging printfs in onMayChangeProcess but I didn't see it as part of the loop. But ShouldLoadURI is.

It looks like we redirect the load into a new process, and then ShouldLoadURI rejects it and starts it in another new process. Repeat.

We should probably do a few things:

  • Not check ShouldLoadURI when we're picking up a redirected load (ResumeRedirectedLoad calls into InternalLoad in that case), since the decision has already been made.

I'm uploading a patch that does this and fixes the problem.

  • Not check ShouldLoadURI for protocols that DocumentChannel makes a decision for (we have some checks in E10SUtils, but they're a subset of DC's protocols).

I also fixed the problem by making the list in E10SUtils.jsm match the one in nsDocShell.cpp Is that what you meant with this bullet point.

EIther patch applied by itself fixes the issue. My guess is that we should definitely apply the first and probably also apply the second.

(In reply to Matt Woodrow (:mattwoodrow) from comment #3)

I guess adding logging to the two decision making paths in E10SUtils to understand why we come up with different results would be good too.

Two paths in E10SUtils? There's a big of spagetti in there so I thought it was one tangly path with multiple entry points. Where is the second?

Depends on D57597

Depends on D57598

Attachment #9116625 - Attachment is obsolete: true

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:pbone, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(pbone)

Depends on D57597

Attachment #9116624 - Attachment description: Bug 1597154 - Avoid redirecting loads between processes more than once r=mattwoodrow → Bug 1597154 - pt 1. Avoid redirecting loads between processes more than once r=mattwoodrow
Attachment #9119020 - Attachment description: Bug 1597154 - Remove obsolete comment r=mattwoodrow → Bug 1597154 - pt 2. Fix out-of-date comment r=mattwoodrow
Attachment #9119021 - Attachment description: Bug 1597154 - Defer to documentchannel for process switching for all schemes r=mattwoodrow → Bug 1597154 - pt 3. Defer to documentchannel for process switching for all schemes r=mattwoodrow
Attachment #9116626 - Attachment description: Bug 1597154 - Enable browser_protocolhandler_loop.js for fission r=mattwoodrow → Bug 1597154 - pt 4. Enable browser_protocolhandler_loop.js for fission r=mattwoodrow
Blocks: 1399574
Flags: needinfo?(pbone)
Pushed by pbone@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9580b0a08782 pt 1. Avoid redirecting loads between processes more than once r=mattwoodrow,kmag https://hg.mozilla.org/integration/autoland/rev/cc9c332c22a6 pt 2. Fix out-of-date comment r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/1638767d4977 pt 3. Defer to documentchannel for process switching for all schemes r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/8f8a663e3118 pt 4. Enable browser_protocolhandler_loop.js for fission r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/051d6f3a237c pt 5. Rename SchemeUsesDocChannel r=mattwoodrow
Flags: needinfo?(pbone)

Either of you can take a look, I'm testing these fixes now to see if I can
land this patch series and would also appreciate a review before I commit to
landing them.

Pushed by pbone@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3c34ca1e2079 pt 1. Avoid redirecting loads between processes more than once r=mattwoodrow,kmag https://hg.mozilla.org/integration/autoland/rev/e8dccb59bf2a pt 2. Fix out-of-date comment r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/9857504c26e6 pt 3. Defer to documentchannel for process switching for all schemes r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/6e82c600d52f pt 4. Enable browser_protocolhandler_loop.js for fission r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/dc78c6d3d737 pt 5. Rename SchemeUsesDocChannel r=mattwoodrow

:-(

I want to break this bug up into seperate tasks. One of the troubles getting it to land is that it flips the DC whitelist into a blacklist and that's catching all sorts of problems and therefore also worthy of being it's own unit of work. I'll break other tasks off from this bug also.

Flags: needinfo?(pbone)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: General → DOM: Navigation
Product: Firefox → Core

Once this is fixed, the test in bug 1528305 should be enabled for Fission.

Attachment #9119020 - Attachment is obsolete: true
Attachment #9116626 - Attachment is obsolete: true
Attachment #9116624 - Attachment description: Bug 1597154 - pt 1. Avoid redirecting loads between processes more than once r=mattwoodrow → Bug 1597154 - pt 1. Add a comment about checking GetPendingRedirectedChannel r=mattwoodrow

Refactoring in shouldLoadURI to compute remoteType and wantRemoteType once
and share them on two code paths. This also requires us to change
validatedRemoteType so it can handle more cases where the URI is provided.

Depends on D57597

This fixes 1597154 because the lists of URIs here and in nsDocShell now
match.

Depends on D69135

Attachment #9120671 - Attachment description: Bug 1597154 - pt 5. Rename SchemeUsesDocChannel → Bug 1597154 - pt 4. Rename SchemeUsesDocChannel
Attachment #9119021 - Attachment is obsolete: true
Pushed by pbone@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/853feeec896d pt 1. Add a comment about checking GetPendingRedirectedChannel r=mattwoodrow,kmag https://hg.mozilla.org/integration/autoland/rev/bed6c14b61df pt 2. Refactor shouldLoadURI r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/73c783db555a pt 3. Flip documentchannel whitelist to blacklist r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/08b92b1c769e pt 4. Rename SchemeUsesDocChannel r=mattwoodrow
Blocks: 1626507
Regressions: 1626583
Regressions: 1634272
Blocks: 1402418
Blocks: 1571274
Regressions: 1643578
Regressions: 1653069
Depends on: 1643578
No longer regressions: 1643578
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: