Able to reproduce the issue on the latest canary(54.0.2807.1/ 54.0.2808.0) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04.

This is non-regression issue seen from older chrome version: 30.0.1549.0. Marking this as 'Untriaged' for more inputs on this. 

Hi,

This is very urgent for us. Please let us know if any more info is required from our side.

Please let us know a time-line when we can expect a resolution of this ?

This looks like it's using pdf.js, not the built in PDF viewer in chrome. So, it's possible it's a pdf.js bug and should be filed against them.

Removing the Plugins>PDF label.

The same URL and same file works perfectly in other browsers like Microsoft IE, Mozilla Firefox.

Please help us to resolve the issue.

This might be a fractional units thing. If you zoom and unzoom the image on Linux in 52.0.2743.116 (Official Build) (64-bit), you'll see different borders paint.

Looking at the DIVs in the page, they have fractional widths and positions. (Like on my display "PRODUCT CODE : TM" is 180.078 w * 17 h and at t: 223.862, r: 647.125, b: 1106.140, l: 124.806. It doesn't have a top border.)

This is *probably* paint, but maybe layout just for FYI.

I don't think this is HTML; I think the DIVs are just DIVs.

This is a canvas bug. The entire visible page content is painted into a canvas. 

The text nodes are not even rendering anything visible - you can hide them and the page stays the same. (They probably exist to enable selection).

If you zoom the page in the browser the image is constant. As dominicc says, if you zoom in the app you get very different results at each zoom level.

I am finding this very hard to investigate without a reduced test case.  I have been trying to produce a reduced test, but I am having no success. Perhaps someone with more insight into pdf.js internals could help?

@dhiru0123: Could you help with this?  I would like a small self-contained test that draws just one line that the illustrated the bug.  This could be a small html file or a jsfiddle, or something like that.

@junov, we tried reducing the case, since it comes for table content, we reproduced it with a document containing just one table row. PFA the document and try to debug the case with it.

Deleted: Output.pdf 16.2 KB

Output.pdf 16.2 KB Download

That does not help me much since it still depends on pdf.js to reproduce the problem. What I am looking for is a small self-contained test.

We have plenty of tests that draw thin lines in using 2D canvas and they all pass.  There is something particular about how pdf.js operates that triggers this bug.  I spent a whole day trying to figure out what it could be to no avail. Someone who understands the rendering internals of pdf.js should be able to helps with this. What I am looking for is a tiny snippet of just a few lines of JavaScript that demonstrates the bug.

I'm also trying to coordinate with people from PDF.js if they can help us in this. This bug is also registered in PDF.js bug database.

https://github.com/mozilla/pdf.js/issues/7551

This bug depends on  crbug.com/424291 . The lines that disappear have doAA = false.