New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downloads are failing with state 'interrupted' from custom protocols in 1.8.2-beta.3 #11657

Closed
pfrazee opened this Issue Jan 17, 2018 · 11 comments

Comments

Projects
None yet
6 participants
@pfrazee
Contributor

pfrazee commented Jan 17, 2018

  • Electron version: 1.8.2-beta.3
  • Operating system: MacOS 10.12

Expected behavior

File downloads from custom protocols should complete without issue.

Actual behavior

Before even triggering the custom protocol handler, the download-item emits 'done' with a state of 'interrupted'. In my demo linked below, I use the new registerStreamProtocol, but I was able to reproduce using registerHttpProtocol as well.

How to reproduce

Use https://github.com/pfrazee/electron-download-interrupt-bug

@pfrazee

This comment has been minimized.

Contributor

pfrazee commented Jan 17, 2018

Im booting up my linux box to do some debugging on the electron codebase. Will report what I find (hopefully will be able to PR a fix).

@pfrazee

This comment has been minimized.

Contributor

pfrazee commented Jan 17, 2018

This is getting logged by chromium:

[19102:0117/142535.172538:WARNING:url_request_job_manager.cc(90)] Failed to map: custom://foo.com/index.html
@pfrazee

This comment has been minimized.

Contributor

pfrazee commented Jan 17, 2018

I found the issue. It was introduced by this commit: 6b2ddc4

@tarruda It looks like request->initiator().has_value() is false if webContents.downloadURL() is called, and also when initiated by the PDF download fallback behavior (when plugins are disabled). Either the initiator needs to be set in those cases, or your commit needs to be rolled back or modified.

@pfrazee

This comment has been minimized.

Contributor

pfrazee commented Jan 22, 2018

Would anybody object to a PR which reverts 6b2ddc4 ?

@tarruda

This comment has been minimized.

Contributor

tarruda commented Jan 22, 2018

The main reason I added 6b2ddc4 is to allow interceptStreamProtocol('https') to modify/delegate requests to electron.net. Without this commit, invoking electron.net while intercepting http/https will result in an infinite loop.

In any case, my approach to breaking the infinite loop was was kinda hacky and needs to be fixed. A possible solution is to put URLRequest pointers created by electron.net in a weak set that is checked by MaybeCreateJob. I will send a PR with this fix later this week.

@pfrazee

This comment has been minimized.

Contributor

pfrazee commented Jan 22, 2018

Ok solid, I appreciate it.

@brenca

This comment has been minimized.

Member

brenca commented Jan 29, 2018

@tarruda We use custom protocols that redirect to other custom protocols, and 6b2ddc4 sadly broke that too.

@tarruda

This comment has been minimized.

Contributor

tarruda commented Jan 30, 2018

I've been quite busy these days so couldn't find the time to do it yet, but will probably be able to do this on the weekend.

tarruda added a commit that referenced this issue Feb 1, 2018

Fix protocol filtering of net.request
net::URLRequest inherits from base::SupportsUserData, which allows
associating arbitrary data with the request. Use this mechanism as a
condition for filtering requests from custom protocols.

Fix #11657

tarruda added a commit that referenced this issue Feb 1, 2018

Fix protocol filtering of net.request
net::URLRequest inherits from base::SupportsUserData, which allows
associating arbitrary data with the request. Use this mechanism as a
condition for filtering requests from custom protocols.

Close #11657

tarruda added a commit that referenced this issue Feb 1, 2018

Fix protocol filtering of net.request
net::URLRequest inherits from base::SupportsUserData, which allows
associating arbitrary data with the request. Use this mechanism as a
condition for filtering requests from custom protocols.

Close #11657

jkleinsc added a commit that referenced this issue Feb 16, 2018

Fix protocol filtering of net.request
net::URLRequest inherits from base::SupportsUserData, which allows
associating arbitrary data with the request. Use this mechanism as a
condition for filtering requests from custom protocols.

Close #11657
@alexeykuzmin

This comment has been minimized.

Contributor

alexeykuzmin commented Feb 27, 2018

The fix has landed in master (and 2-0-x) but not in 1-8-x.
@ckerr, @jkleinsc Do we want to backport it to 1-8-x?

jkleinsc added a commit that referenced this issue Mar 2, 2018

Fix protocol filtering of net.request
net::URLRequest inherits from base::SupportsUserData, which allows
associating arbitrary data with the request. Use this mechanism as a
condition for filtering requests from custom protocols.

Close #11657

(cherry picked from commit bc76f35)
@jkleinsc

This comment has been minimized.

Contributor

jkleinsc commented Mar 2, 2018

@alexeykuzmin I'll backport to 1-8-x

@alexeykuzmin

This comment has been minimized.

Contributor

alexeykuzmin commented Mar 5, 2018

@alexeykuzmin I'll backport to 1-8-x

Was backported in #12100.

sethlu added a commit to sethlu/electron that referenced this issue May 3, 2018

Fix protocol filtering of net.request
net::URLRequest inherits from base::SupportsUserData, which allows
associating arbitrary data with the request. Use this mechanism as a
condition for filtering requests from custom protocols.

Close electron#11657
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment