Opened 8 years ago
Closed 7 years ago
#13085 closed bug (duplicate)
Webpositive does not create download folder
Reported by: | vidrep | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | #11632 | Blocking: | |
Platform: | All |
Description
hrev50700 x86_gcc2 Do a fresh install of Haiku on a HD partition. Open Webpositive->Window->Settings Download Folder: /boot/home/Downloads ->Apply Go To: http://download.haiku-os.org/nightly-images/x86_gcc2_hybrid/ Clicking on "anyboot" creates a zip file named "Downloads" in the home folder, instead of the expected behaviour of creating a directory called Downloads in which the downloaded anyboot image will go. (see attached screenshot1.png)
Attachments (2)
Change History (9)
by , 8 years ago
Attachment: | screenshot1.png added |
---|
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 7 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
This issue has appeared again with HaikuWebKit 1.6.2 on hrev51369 x86_64 I have attached a screenshot.
Note that it created a 22KB zip named "Downloads" which is the same size as the file I clicked on (haikuwebkit_devel-1.6.2-1-x86_64.hpkg)
by , 7 years ago
Attachment: | Downloads.png added |
---|
comment:4 by , 7 years ago
patch: | 0 → 1 |
---|
comment:5 by , 7 years ago
comment:6 by , 7 years ago
Summary: | Webpositive Downloads Settings → Webpositive does not create download folder |
---|
comment:7 by , 7 years ago
Blocked By: | 11632 added |
---|---|
Resolution: | → duplicate |
Status: | reopened → closed |
This is a different manifestation of #11632.
When a directory exists, we create files named -0, -1, ... inside it. When the download directory does not exist, we create a file with its name, then name-1, name-2, etc.
By the way, all these issues (also the other ones with about:blank which you reopened, and some more), are not really related to the haikuwebkit version. They are all tied to a race condition (two threads getting out of sync) somewhere in the HTTP code, which triggers more or less easily depending on your machine, network speed, and the webkit code which just happens to have different timings in each version. Hence the issue will come and disappear again until we can catch and fix the root problem.
I cannot reproduce on latest HaikuWebKit 1.5.4 release. Ticket can probably be closed.