Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Torrent Save file gives 0 as default file name #6737

Closed
srirambv opened this issue Jan 19, 2017 · 2 comments · Fixed by #7154
Closed

Torrent Save file gives 0 as default file name #6737

srirambv opened this issue Jan 19, 2017 · 2 comments · Fixed by #7154
Labels
bug feature/torrent QA/test-plan-specified release-notes/include

Comments

@srirambv
Copy link
Collaborator

Did you search for similar issues before submitting this one?
Yes

Describe the issue you encountered:
Torrent Save file gives 0 as default file name

Expected behavior:
Should give the actual file name

  • Platform (Win7, 8, 10? macOS? Linux distro?):
    Windows 10 x64

  • Brave Version (revision SHA):
    Brave 0.13.0
    rev c60b783

  • Steps to reproduce:

    1. Download from any torrent magnet link
    2. Click on the save file button in the torrent viewer
    3. File name is 0 in the save dialogue prompt

  • QA Steps :

    1. Download from any torrent magnet link
    2. Click on the save file button in the torrent viewer
    3. Save dialogue prompt should contain the actual filename

  • Screenshot if needed:
    savetorrent

  • Any related issues:
    cc: @bbondy
@srirambv srirambv added this to the 0.13.1 milestone Jan 19, 2017
@bbondy bbondy removed this from the 0.13.1 milestone Jan 19, 2017
@feross feross mentioned this issue Feb 10, 2017
Merged
feross added a commit to webtorrent/webtorrent that referenced this issue Feb 10, 2017
@feross
Refactor http server; support content-disposition
dd86f01 
Refactored the server into many smaller functions to make it easier to
understand all the different code paths.

- added a Content-Disposition header, which tells the browser the
file's name, since we use urls like http://localhost:port/0 <-- no
human-readable file name
- Server returns valid HTML documents (with all the required tags) now.
- Return 204 status for OPTIONS request
- reduce access-control-max-age to chromium max of 600s
- respond to OPTIONS requests that lack
'access-control-request-headers' (before they were treated as GET)
- return '405 invalid verb' for all other verbs

For: brave/browser-laptop#6737
@feross
Copy link
Contributor

feross commented Feb 10, 2017 •
edited
Loading

We can fix this with a 'Content-Disposition' header in the WebTorrent server.

In the past, I've found just setting a download attribute on the link like <a href='#' download='filename.mp4'> was sufficient to control the filename in the absence of a 'Content-Disposition' header. However, Chrome stopped obeying the download attribute for links on other domains (CORS).

Now the 'Content-Disposition' header is the only way to control it then.

PR out to WebTorrent here: webtorrent/webtorrent#1039 Tested and confirmed it fixes the issue.

cc @bbondy @BrendanEich

@feross feross mentioned this issue Feb 10, 2017
Merged
4 tasks
@feross
Copy link
Contributor

feross commented Feb 10, 2017 •
edited
Loading

PR is merged and released to npm: webtorrent/webtorrent#1039

PR sent to bump webtorrent-remote so we get the fix in Brave: #7154

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug feature/torrent QA/test-plan-specified release-notes/include
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Bump webtorrent-remote dependency
4 participants
@feross @bbondy @luixxiul @srirambv