Fix the display of the indeterminate progress bar when the loaded percentage is NaN (issue 4696)

[Snuffleupagus]

Should (hopefully) fix #4696.

@joepie91 Does this patch fix the issue?

[Snuffleupagus]

Seems to have regressed a year ago in PR #3124.

/botio-linux preview

[pdfjsbot]

From: Bot.io (Linux)

---

Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://107.21.233.14:8877/019dbf5f3c5d6bd/output.txt

[pdfjsbot]

From: Bot.io (Linux)

---

Success

Full output at http://107.21.233.14:8877/019dbf5f3c5d6bd/output.txt

Total script time: 0.38 mins

Published

• Viewer: http://107.21.233.14:8877/019dbf5f3c5d6bd/web/viewer.html
• B2G Viewer: http://107.21.233.14:8877/019dbf5f3c5d6bd/extensions/b2g/content/web/viewer.html
• Extension: http://107.21.233.14:8877/019dbf5f3c5d6bd/extensions/firefox/pdf.js.xpi
• Extension (AMO): http://107.21.233.14:8877/019dbf5f3c5d6bd/extensions/firefox/pdf.js.amo.xpi

[joepie91]

Hmm. What is the intended behaviour of the loading bar when the Content-Length is unknown? The only change this pull request appears to introduce (on my system, anyway), is that it briefly flashes 'filled' when finishing loading the document - otherwise, it still appears static and "stuck", and gives no visual cue that the document is loading.

[joepie91]

Whoops, scratch that, turns out my testcase was flawed. Since I'm testing locally, I had to introduce a sleep() to simulate a large download, but didn't realize that the progress bar would only start displaying upon receiving the first byte. It seems to work correctly with this patch applied, when I make sure to send some data before I sleep().

Technical functionality aside, from a visual point of view, the animation seems to be running a little fast. It's running so fast that it's actually flickering (I don't have vertical synchronization enabled). Perhaps it might be worth slowing that down a little?

[Snuffleupagus]

from a visual point of view, the animation seems to be running a little fast.

I agree that it moves too quickly currently. I also think that the colours used makes the moving part a bit difficult to spot against the background.

Perhaps it might be worth slowing that down a little?

That would have to be done in a follow-up PR, since I think that we should get feedback from the UI designer before making those kind of changes.

[joepie91]

That would have to be done in a follow-up PR, since I think that we should get feedback from the UI designer before making those kind of changes.

I agree. Just figured it'd be worth it to share my concerns here first, in case there was a good reason for it :)

[yurydelendik]

Thanks