#4385 closed defect (fixed)
Browse: opening a PDF the second time shows bad download progress
| Reported by: | manuq | Owned by: | humitos |
|---|---|---|---|
| Priority: | Unspecified by Maintainer | Milestone: | |
| Component: | Browse | Version: | Unspecified |
| Severity: | Unspecified | Keywords: | upstream, r+ |
| Cc: | manuq, godiard, humitos | Distribution/OS: | Unspecified |
| Bug Status: | Unconfirmed |
Description
TestCase:
- Click on a link with a large PDF file, for example the one in this page: http://wiki.sugarlabs.org/go/File:Dt19.pdf
- The progress can be seen in the url entry. Cancel it at about 50%, closing the tab or clicking the X icon in the entry.
- Click on the link again and wait.
The progress will not be displayed until it reaches 50%. That is, it will start displaying after it passes the reached percent. If the PDF was downloaded and displayed, closing and opening it again will not show any progress at all.
Expected behaviour: always show the progress.
Maybe this means that webkit can remember the downloaded bits. In that case, Browse doesn't seem to take adventage of that, because the long wait shows that it is downloading them again.
Attachments (2)
Change History (7)
Changed 10 years ago by humitos
comment:1 Changed 10 years ago by humitos
Attached there is a Test Case for this. The idea is to download the same file twice or more times to see that the notify::progress signal is emitted when the previous value of progress is reached. However the file is not resumed, it's downloaded from scratch the second time.
This seems to be a bug on webkit. I'm asking on #webkit about this.
comment:2 Changed 10 years ago by humitos
- Cc manuq added
- Keywords upstream added
Upstream bug report:
comment:3 Changed 10 years ago by humitos
- Cc godiard humitos added
- Keywords r? added
comment:4 Changed 10 years ago by manuq
- Keywords r+ added; r? removed
- Resolution set to fixed
- Status changed from new to closed
Upstream didn't answer. Pushed workaround as 5234aee5 .
Test Case