User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Created a pdf from the following PostScript:
1 setlinecap 5 setlinewidth 100 100 moveto showpage

Opened it, using file:/// ... in firefox

Actual results:

blank page is displayed

Expected results:

A black dot should be displayed

NOTE: this appears to be a bug in every browser I've tried, using the built-in pdf viewer. Adobe Acrobat has no problem rendering the file properly.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

I'm unable to reproduce on Linux or MacOS. Unfortunately, I don't have access to windows right now.

Just tried this with firefox 77.0b5 (64-bit) on Windows 10 Home 1909 build 18363.836
The correct row of 3 dots appears, but so does a row of 3 squares above it, which is wrong. Only when linecap is set to 1 should anything appear, the offending row has linecap set to 2.
(The three rows in test.pdf have linecaps of 0, 1, and 2 starting with the bottom row (that correctly doesn't show anything))

Hi Brendan, an S1 or S2 bug needs an assignee - could you find someone for this bug?

Just tried this with Firefox 83.0, as well as Chrome (and Edge) 87.0
Behavior has reverted to blank page.
Particularly annoying with https://raw.githack.com/ms0/docs/main/gmovie.pdf where the graphs starting on pages 6 thru 62 are missing all their data points.

Tried this with Firefox 90.0.2, and it still doesn't work on Windows 10. The original test file can also be found at http://raw.githack.com/ms0/test/master/test.pdf
Doesn't work in edge or chrome either. In all these browsers, test.pdf produces a blank page.
However, it does (somewhat) work on my iPad in Safari, Firefox, and Chrome, although test.pdf produces a spurious row of diamonds above the (correctly rendered) row of dots.
The Adobe Acrobat rendering is the gold standard here.

For the first point we've:

1000 1000 m
h
S

So, on the canvas it can be translated into:

ctx.moveTo(1000, 1000);
ctx.closePath();
ctx.stroke();

and according to the closePath doc:
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/closePath
then nothing is drawn here.
We should track what we've in the path in order to be able to add in this case a lineTo to have something to draw.

The problem is that javascript and pdf are incompatible in the way they handle closepath of a single point. I don't believe it is possible to use the javascript version to simulate the pdf version if you build the path in the obvious way, because the pdf rendering depends on linecap, and that can be set after the path has been built. Given that the path is not readable in javascript, the only solution I see is to build the path in a separate data structure, and turn it into an equivalent javascript path that depends on linecap and possibly linewidth at the time it is stroked. (Alternatively, the community could realize that the pdf handling of paths is "correct" and the javascript handling is "wrong", and change the javascript spec and resulting implementations to be pdf compatible. Or perhaps, more plausibly, just add a pdf mode to the context or a pdfstroke method to render paths the way pdf does.)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.