amysamudi@ -- Thanks for reporting this issue. Could you please provide the OS and Device details, Chrome Version along with the sample PDF file where the issue is reproduced.

Sharing screen cast would be helpful for us to understand the issue better.

Thanks in advance!

I have also run into this issue on desktop in our internal application. I've been able to reproduce it in 64.x & 65.0.3325.162, but not in 63.0.3239.132. See the attached screenshot. Using the controls I can normally not even zoom out that far.

Sadly I have not been able to reproduce the problem in a minimal example. Even in our application I can not reproduce it 100% of the time. We are loading the PDF in an iframe by passing the PDF URL in the src attribute.

I've been able to somewhat circumvent the problem by specifying open PDF parameter '#view=FitH'. This does prevent the PDF from being displayed zoomed out very far. However, the PDF appears to be opened in a random place in the document, and adding 'page=1' or 'view=FitH,0' does not have any effect.

I noticed the open PDF parameters are not having any effect in my 63.x version, where I do not experience the issue. Could the introduction of the parameters be related to this issue?

Deleted: tiny.png 7.5 KB

	tiny.png 7.5 KB View Download

Could this be related to your params work?

Sounds like it could, but I don't see why it would without specifying a "view=". Can you provide a URL that reproduces this, even if it's not 100% or minimal?

I imagine this isn't actually on Android.

Managed to reproduce the behaviour in a small example. It seems to be related to collapsible elements.

Opening this page in 63.0.3239.132 shows the PDF fairly small, but still somewhat viewable. But opening it in the latest version results in the very zoomed out version as shown in the above screenshot.

Deleted: index.html 5.4 KB

index.html 5.4 KB View Download

Able to reproduce with the provided html, thank you.

Bisect points at range:

https://chromium.googlesource.com/chromium/src/+log/b904e99561e159a2f801b311fb33f980d2a7caa2..85a1bf73c32a1cda0d34fceb7a20f96b26bba035

Likely culprit is: https://chromium-review.googlesource.com/c/chromium/src/+/740683

Fady, can you please take a look?

 Issue 812154  has been merged into this issue.

Sorry, likely culprit is: https://chromium-review.googlesource.com/c/chromium/src/+/741246.

The link was wrong, all else should still be correct.

Good first surface sync bug for jonoross@ I think.

I can still reproduce this on 68.0.3440.106
However on ToT (07dd5b91d0e88844bfc2a5f121fce15d0dfb1074) I cannot reproduce this anymore.

There's been a log of surface sync work going on this the patch in #9
The sections of code changed by #9 are different now, so it looks like this was addressed in other work.

If anyone can reliably reproduce this on ToT, so likely R-70, please feel free to reopen.

I tried r586305 and it's broken for me. Can anyone else try near ToT and see how it behaves?

Have a repro on ToT today r586663 but only release build, not debug.

Investigating

+thestig@ and hnakashima@ for comments on what would be an appropriate fix:

So it appears that surface synchronization has changed the order of certain operations for the PDF Viewer.

Currently when a new size is set on RenderWidgetHostViewGuest it will not report that size until the visual properties synchronization has completed.

This breaks chrome/browser/resources/pdf/viewport.js

Previously when setDocumentDimensions was called to set "initialDimensions" there was already a set "this.window_.innerWidth" and "this.window_.innerHeight" This would allow for the initial zoom to be set accordingly.

However it is now possible for the initial document dimensions to be set before surface synchronization has completed. This leaves a 0x0 sized window to be used for calculating the initial zoom. Hence the fully zoomed out PDF.

Once the visual properties have been synchronized resize_ is called, at which point the correct window size is available. Unfortunately this only updates the zoom if there is a fittingType present. In case like this example there is no fit type, so zoom isn't updated.

It seems that viewport.js needs to begin updating the zoom level in these cases. For the initial call to setDocumentDimensions it forces the initial zoom calculation to use "fitWidth" however I'm not sure if that is the appropriate way to fix this case.

hnakashima@ I've put up a partial fix change: https://chromium-review.googlesource.com/c/chromium/src/+/1196764

However forcing a fit on the zoom feels incorrect. Even though it is following what setDocumentDimensions.

There's also a bug in that the two zooms occurring lead to the document being scrolled to the bottom.

A more complete scenario might be blocking doing the work in setDocumentDimensions until there is a non-zero innerWidth/innerHeight.

Could you take a look at this?

Thanks for investigating, I'll take a look.

I think the right way to fix this is not forcing a fit, but setting whatever zoom level is set on first load - which is probably just setting it to the default level.

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

commit 4cf9ed4de53a882d27203bf191f09ddd76ca3e0e
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Fri Sep 07 21:02:03 2018

Delay zoom calculation until window has a non-zero size.

Bug:  819421 
Change-Id: Idf4c66ed52d8b279ec54c9aa0977a7dba58f332b
Reviewed-on: https://chromium-review.googlesource.com/1204719
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589631}
[modify] https://crrev.com/4cf9ed4de53a882d27203bf191f09ddd76ca3e0e/chrome/browser/resources/pdf/viewport.js