Able to reproduce this issue on Mac OS 10.12.6 using chrome latest dev #63.0.3218.0.

Manual Bisect Info:
===================
Good Build:63.0.3213.3
Bad Build: 63.0.3214.0


Bisect Information:
====================
You are probably looking for a change made after 501343 (known good), but no later than 501344 (first known bad).

CHANGELOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/fdaaebe87184d49b49de78b006ea79ef49f14afd..af1b4342b81d3058d635920ec49219028b3fa220

Suspecting https://chromium.googlesource.com/chromium/src/+/af1b4342b81d3058d635920ec49219028b3fa220 from above URL

@thestig :Could you please take a look and reassign to the right owner if it is not related to your change.

On latest dev #63.0.3219.0 all ok.

Deleted: Screencast 2017-09-18.mp4 600 KB

	Screencast 2017-09-18.mp4 600 KB View Download

Able to reproduce the issue on latest canary 63.0.3222.0 on Ubuntu 14.04, Windows and Mac 10.12.6.

Delay is seen in status load bar.. For First few secs, no status load bar is seen..

thestig@,
Friendly ping!
Could you please take a look as it is marked as stable blocker.
Thanks..!

I have reproduced this problem only once. In case when network was slowdown. I suggest, this problem is related to the hung of network. To fix this, I propose use fake progress. As result the progress bar will be shown immediatly in all cases.
This is CL for that:
https://chromium-review.googlesource.com/c/chromium/src/+/684714

Do we only show the status bar after data has been received? Can we just make it appear sooner? Showing a fake status bar doesn't seem like something we'd want to do in the long run.

>> Do we only show the status bar after data has been received?
Yes.

>> Can we just make it appear sooner?
And what progress state should it have?

>> Showing a fake status bar doesn't seem like something we'd want to do in the long run.
This is forcing appear it sooner (as you say), with valid (non zero percent) state which slowly increasing to reduce brake sensation.

This is not replacement for real progress, this is just addition.

It should load the progress bar and it should be set to 0 data. We shouldn't pretend we're receiving data when we aren't, that's just going to be confusing for the user.

The progress bar with 0% value is equal to invisible progress bar. Because the progress bar is just blue line with length equals to progress value (zero length in your case).

So, it sounds like we could either make it appear at 0%, or just set it to 1 as the starting value, or 0.1 or something small.

Why wasn't this an issue with the old code?

I see only one different with original code in this case. This is read buffer size, which was changed in
https://codereview.chromium.org/2525903002

Also i think it is can be reproduced in old code two, but in new code i have reproduced it just once from much of trying.

My manual bisect points to https://chromium-review.googlesource.com/c/chromium/src/+/679856

To be clear, here it's working: refs/heads/master@{#504060} and here it's not appearing: refs/heads/master@{#504061}

Also note in the screenshots how the title in the toolbar is incorrectly aligned after this CL.

My guess is the problem was introduced (Original Report), fixed (Comment #5), then introduced back in 504061.

Deleted: 504060.png 242 KB

	504060.png 242 KB View Download

Deleted: 504061.png 256 KB

	504061.png 256 KB View Download

@hnakashima: The alignment problem is probably a side effect of my CL. I think it should be tracked separately than this bug though, since the bug was filed before https://chromium-review.googlesource.com/c/chromium/src/+/679856 landed.

The CL that changes the alignment also causes the loading to disappear, though. As I said in comment #15, I think the bug had been fixed and was reintroduced - which is a weird coincidence, but it's what I'm seeing.

Ok. I can verify that https://chromium-review.googlesource.com/c/chromium/src/+/679856 regressed the showing of the progress bar, and the alignment. Fixing...

FYI candidate fix is at https://chromium-review.googlesource.com/c/chromium/src/+/685363.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bebb7ae2fbc797046e89f675c18e31c5690368cd

commit bebb7ae2fbc797046e89f675c18e31c5690368cd
Author: dpapad <dpapad@chromium.org>
Date: Thu Sep 28 00:43:11 2017

PDF viewer: Fix toolbar regressions after removing paper-toolbar.

 - Restore 16px left/right padding.
 - Make progress bar visible again.

Bug:  766046 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I5c9f3a6ca5117b0c7ed12ccd0cb9b2c7eae10c58
Reviewed-on: https://chromium-review.googlesource.com/685363
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504826}
[modify] https://crrev.com/bebb7ae2fbc797046e89f675c18e31c5690368cd/chrome/browser/resources/pdf/elements/viewer-pdf-toolbar/viewer-pdf-toolbar.html

The regression mentioned in comment #15 should be fixed now. I don't think there is anything else to do with this bug, so closing. Please re-open if that is not the case.

Issue is still reproducible on 63.0.3226.0 dev in Ubuntu 14.04, Windows and Mac. Attaching screencast for reference.

Fixed revision[504826] from comment#20 is less than latest revision[504841].

@dpapad: Could you please confirm which build consists the fix.

Thanks!

Deleted: StatusLoadbar.ogv 1.4 MB

	StatusLoadbar.ogv 1.4 MB View Download

I am not able to reproduced on today's Canary on Mac (63.0.3226.0). See screencast where the progress bar appears.

@keerthana.v: Are you sure you are using the latest build? Can you try Canary?

Deleted: progress_bar.mov 9.2 MB

progress_bar.mov 9.2 MB Download