[e10s] Redirect to local file does not work

RESOLVED FIXED in Firefox 55

Status

()

defect
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: winflip, Assigned: u408661)

Tracking

51 Branch
mozilla55
Points:
---

Firefox Tracking Flags

(firefox55 fixed)

Details

(Whiteboard: [necko-active])

Attachments

(1 attachment)

Reporter

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

1. Disable all extensions.
2. Make sure the prefs are set up to allow local file links to your site
3. Have your site do a 302 redirect to your local file (file:///c:/foobar )

I have made a quick test site with instructions here for you to reproduce the issue: http://skyqueen.cc/testfiles.html


Actual results:

Corrupted Content Error
The site at foobar has experienced a network protocol violation that cannot be repaired.

The page you are trying to view cannot be shown because an error in the data transmission was detected. 
Please contact the website owners to inform them of this problem.


Expected results:

Same behaviour as a direct link to my local file; it displays or offers to download the local file.

Steps to workaround: install some type of extension. I have not figured out why some fix this issue and others don't. A very simple one is https://addons.mozilla.org/en-US/firefox/addon/clear-cache-button/ Merely installing this makes the issue go away.

Comment 1

2 years ago
That sounds like a duplicate of bug 1303727. Could you test with e10s disabled.
Flags: needinfo?(winflip)
Reporter

Comment 2

2 years ago
Confirmed that bug does not appear with e10s disabled, but it does not seem like a duplicate, because the bug still exists when tested in firefox 53.0a2 (2017-03-06) (32-bit) it is still there while  bug 1303727 is considered fixed in that version.
Flags: needinfo?(winflip)

Updated

2 years ago
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Security: Process Sandboxing
Ever confirmed: true
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Summary: Redirect to local file does not work unless some extension is present → [e10s] Redirect to local file does not work

Updated

2 years ago
Flags: needinfo?(bobowencode)
Whiteboard: sbwc2
The same thing happens with the sandbox turned off, so I don't think this is a sandboxing issue.
I'm guessing this affects all platforms using e10s.

Given that normal redirects are working, this is probably a CAPS issue with e10s.
Component: Security: Process Sandboxing → Security: CAPS
Flags: needinfo?(bobowencode) → needinfo?(bobbyholley)
OS: Windows 10 → All
Hardware: x86_64 → All
Whiteboard: sbwc2
Flags: needinfo?(bobbyholley) → needinfo?(mrbkap)
I'm planning to look more at this tomorrow, but my first thought is that this is related to the file process we implemented earlier (in order to enable the sandbox but not part of the sandbox). Bob, do you have any thoughts here?
Flags: needinfo?(mrbkap) → needinfo?(bobowencode)
(In reply to Blake Kaplan (:mrbkap) from comment #4)
> I'm planning to look more at this tomorrow, but my first thought is that
> this is related to the file process we implemented earlier (in order to
> enable the sandbox but not part of the sandbox). Bob, do you have any
> thoughts here?

This happens in release (and back as far as 45 although the behaviour changes slightly).
The file content process is only preffed on in Nightly and the changes didn't land until Fx53, so it seems it is just an e10s/CAPS issue.
I'd look into it further myself, but I'm pretty swamped at the moment, sorry.
Flags: needinfo?(bobowencode)
(In reply to Bob Owen (:bobowen) from comment #5)

> This happens in release (and back as far as 45 although the behaviour
> changes slightly).

Just to be clear ... I should have said "as far as at least 45", I didn't check further back.
Sorry, yeah. This just never worked in e10s. The first obvious problem is that nsFileChannel doesn't implement nsIChildChannel (see also bug 1058551 which made redirects to data URIs work correctly). So, fixing this bug will involve, at the very least, fixing that problem. After that's fixed, I am curious whether the existing redirect code is robust enough to handle the redirect to the file process.

I don't have time to work on this myself. Jason, is there anyone on the necko team that has the cycles to look into this?
Flags: needinfo?(jduell.mcbugs)
Assignee

Updated

2 years ago
Assignee: nobody → hurley
Component: Security: CAPS → Networking: File
Whiteboard: [necko-active]
Assignee

Updated

2 years ago
Flags: needinfo?(jduell.mcbugs)
Comment hidden (mozreview-request)
Assignee

Comment 9

2 years ago
This patch is almost entirely shamelessly stolen from the one in bug 1058551. It's also, fortunately, all we need.

Comment 10

2 years ago
mozreview-review
Comment on attachment 8858117 [details]
Bug 1345094 - make http redirects to file:// uris work under e10s.

https://reviewboard.mozilla.org/r/130088/#review132984

::: netwerk/ipc/PFileChannel.ipdl:14
(Diff revision 1)
> +include URIParams;
> +
> +namespace mozilla {
> +namespace net {
> +
> +async protocol PFileChannel

please write comment what this is used for, every new interface or class has to have it.

::: netwerk/protocol/file/nsFileProtocolHandler.cpp:200
(Diff revision 1)
> +        chan = new mozilla::net::FileChannelChild(uri);
> +    } else {
> +        chan = new nsFileChannel(uri);
> +    }
>      if (!chan)
>          return NS_ERROR_OUT_OF_MEMORY;

when you are here, maybe remove the nonnull check?
Attachment #8858117 - Flags: review?(honzab.moz) → review+
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 13

2 years ago
Pushed by hurley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a3953fb9958d
make http redirects to file:// uris work under e10s. r=mayhemer

Comment 14

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/a3953fb9958d
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.