8000 Downloads are failing with state 'interrupted' from custom protocols in 1.8.2-beta.3 · Issue #11657 · electron/electron · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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
Closed

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

pfrazee opened this issue Jan 17, 2018 · 11 comments
Labels
bug 🪲 platform/macOS version/1.8.x

Comments

@pfrazee
Copy link
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 pfrazee mentioned this issue Jan 17, 2018
Closed
@pfrazee
Copy link
Contributor Author
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
Copy link
Contributor Author
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
Copy link
Contributor Author
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
Copy link
Contributor Author
pfrazee commented Jan 22, 2018

Would anybody object to a PR which reverts 6b2ddc4 ?

@tarruda
Copy link
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
Copy link
Contributor Author
pfrazee commented Jan 22, 2018

Ok solid, I appreciate it.

@brenca
Copy link
Contributor
brenca commented Jan 29, 2018

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

@tarruda
Copy link
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
@tarruda
Fix protocol filtering of net.request
2093a36 
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
@tarruda
Fix protocol filtering of net.request
d140702 
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 tarruda mentioned this issue Feb 1, 2018
Merged
tarruda added a commit that referenced this issue Feb 1, 2018
@tarruda
Fix protocol filtering of net.request
8bc7612 
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 pushed a commit that referenced this issue Feb 16, 2018
@tarruda
Fix protocol filtering of net.request
bc76f35 
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
Copy link
Contributor
alexeykuzmin commented Feb 27, 2018 •
edited
Loading

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 pushed a commit that referenced this issue Mar 2, 2018
@tarruda
Fix protocol filtering of net.request
c3da3ae 
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
Copy link
Member
jkleinsc commented Mar 2, 2018

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

@alexeykuzmin
Copy link
Contributor

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

Was backported in #12100.

sethlu pushed a commit to sethlu/electron that referenced this issue May 3, 2018
@tarruda @sethlu
Fix protocol filtering of net.request
ac5151c 
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
Assignees
No one assigned
Labels
bug 🪲 platform/macOS version/1.8.x
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@alexeykuzmin @jkleinsc @tarruda @pfrazee @brenca @sofianguy
0