[Bug]: Background is pink when using background: repeating-linear-gradient

[muster-mark]

Minimal, reproducible example

const puppeteer = require("puppeteer");

async function main() {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await page.setContent('<div>I\'m a Barbie div in a Barbie world.</div><style>div {height: 200px; width: 200px; background: repeating-linear-gradient(-45deg, #111, #111 10px, #222 10px, #222 20px) }</style>');
    await page.pdf({
        path: 'output.pdf',
        printBackground: true,
    });

    await browser.close();
}

main();

Error string

nO eRrOR

Bug behavior

• Flaky
• PDF

Background

I want to have a stripy background, so tried to use the css property intended for this.

Expectation

I expected to get a stripy background.

Reality

I got a pink background.

Puppeteer configuration file (if used)

No response

Puppeteer version

22.6.5

Node version

18.20.2

Package manager

npm

Package manager version

10.5.0

Operating system

Linux

[github-actions]

The issue has been labeled as confirmed by the automatic analyser.
Someone from the Puppeteer team will take a look soon!

---

Analyzer run

[OrKoN]

@muster-mark could you please provide a PDF that you get?

[OrKoN]

Do you get a different result if you print using the regular print dialog in Chrome and choose save to PDF?

[Lightning00Blade]

This looks like an issue with the viewer that's being used
From my VSCode extension I get the described problem (Also I get a File is corrupted error):

But opening the same file in Chrome give the correct color:

[muster-mark]

@OrKoN @Lightning00Blade
Please see attached printed_from_puppeteer.pdf and printed_from_chrome.pdf

printed_from_chrome.pdf
printed_from_puppeteer.pdf

Lighting00Blade, you are correct that it does depend on the viewer. I was using Firefox to view the pdfs. It displays correctly in Chrome, as you note, and also Adobe Acrobat reader. Though OrKoN, yes I do get a different result when printing from chrome, as that pdf displays correctly in Firefox.

I am not sure we can we be sure the viewers are to blame here, since the issue is apparent in 2 separate viewers (Firefox and vscode). Perhaps the pdf itself is in fact the issue, but chrome and adobe acrobat are more tolerant of whatever that issue is.

[OrKoN]

So if it is shown correctly in Chrome and Adobe Acrobat reader, I believe this is an issue with the specific PDF viewer.

[muster-mark]

@OrKoN FWIW Safari also seems to have an issue with the puppeteer file. Although it displays it correctly, it takes an astonishing 35 seconds to render the table, whereas the pdf created by printing in chrome renders almost immediately. That's despite the table being a lot smaller in the puppeteer-generated file (I realise now I did not print the same exact thing in the 2 pdfs).

[muster-mark]

@OrKoN Also, Apple Preview renders the chrome generated version instantantaneously, but takes about 5s for the puppeteer one.

[OrKoN]

@muster-mark Puppeteer's one are also generated by Chrome as Puppeteer does not generate PDFs on its own. Have you tried tagged: false in Puppeteer? Perhaps it is worth filing a bug at crbug.com ?

[muster-mark]

@OrKoN Yes I merely meant the one created by printing directly in Chrome. tagged: false produces the same output. But actually in Firefox it does look like this known issue: mozilla/pdf.js#5046