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.

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

Using "add folder" does not add a folder correctly [0.7.2] #884

Closed
DavidBurela opened this issue Mar 20, 2019 · 4 comments · Fixed by #927
Closed

Using "add folder" does not add a folder correctly [0.7.2] #884

DavidBurela opened this issue Mar 20, 2019 · 4 comments · Fixed by #927
Assignees
Labels
kind/bug A bug in existing code (including security flaws)

Comments

@DavidBurela
Copy link

DavidBurela commented Mar 20, 2019

  • OS: win32
  • IPFS Desktop Version: 0.7.2
  • Electron Version: 4.0.8
  • Chrome Version: 69.0.3497.128

Dragging a folder into the web ui, will add it correctly.
But clicking "add folder" seems to add an empty folder, that if you try to navigate into will result in it just continuously trying to load.

I have included a screencapture gif to show the bug.

BF29E87D-D9A4-4005-914E-DF3BEEA09E28

@hacdias
Copy link
Member

hacdias commented Mar 20, 2019

Hey again @DavidBurela! Once again, sorry. Yes, I can reproduce this 😞For me I get a "Failed to add to IPFS". I don't even get an empty folder. @olizilla @fsdiogo could you take a look at this one, please?

@hacdias hacdias added the kind/bug A bug in existing code (including security flaws) label Mar 20, 2019
@olizilla
Copy link
Member

olizilla commented Mar 20, 2019

interesting! I can't recreate this in Chrome 72 or Firefox 65, but I can on the 0.7.2 desktop release.

In chrome 72 via webui adding a folder via the folder input leads to us sending an add request with

----------------------------872277512022848910475489
Content-Disposition: file; filename="foox%2FUntitled.txt"
Content-Type: application/octet-stream

hello world
----------------------------872277512022848910475489--

and we get the response

{"Name":"foox/Untitled.txt","Bytes":11}
{"Name":"foox/Untitled.txt","Hash":"Qmf412jQZiuVUtdgnB36FXFX7xg5V6KEbSJ4dpQuhkLyfD","Size":"19"}
{"Name":"foox","Hash":"QmbdfJiE1XZRJVmxQAvArWpDz89jno5cRKpZGpQqFJvMiz","Size":"77"}

but when we do the same thing in ipfs-desktop, we're sending

----------------------------323655909678229599284643
Content-Disposition: file; filename="Desktop%2Ffoox"
Content-Type: application/octet-stream


----------------------------323655909678229599284643--

and we get the response

{"Name":"Desktop/foox"}
{"Name":"Desktop/foox","Hash":"QmbFMke1KXqnYyBBWxB74N4c5SBnJMVAiMNRcGu6x1AwQH","Size":"6"}
{"Name":"Desktop","Hash":"QmaVFREPrsbhyjViXGo8DkKSHSG2go1Dpxhpob5aPBFfrp","Size":"56"}

so it looks like the version of chromium in desktop has a different opinion about how the file path info for folders added via file input elements should be provided, which is another fun edge-case for that logic to deal with.

@olizilla
Copy link
Member

olizilla commented Apr 9, 2019

@hacdias can you take a look at this?

@hacdias
Copy link
Member

hacdias commented May 13, 2019

Note to self: electron/electron#839

This was referenced May 13, 2019
@ghost ghost assigned hacdias May 13, 2019
@ghost ghost added the in progress label May 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants