Closed Bug 1769429 Opened 2 years ago Closed 2 years ago

background-position property crops the left side of the background image with a negative x coordinate, but it is disabled when printing

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
Unspecified
Windows
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
104 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 --- fixed
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- fixed
firefox104 --- fixed

People

(Reporter: earlgreypicard, Assigned: jrmuizel)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

test-case.html
1.70 KB, text/html
Details
test-case.jpg
44.52 KB, image/jpeg
Details
jorudan.jpg
193.11 KB, image/jpeg
Details
Bug 1769429. Revert 1719215.
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr102+
Details | Review
Attached file test-case.html —

User Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

  1. Start Firefox.
  2. Open the attached test-case.html.
  3. Hit Ctrl + P.
  4. Access Options and check "Print backgrounds".
  5. Click "Print".

Actual results:

The background image is shifted in the browser display and preview, but only the x-direction shift is disabled in the print result.

Expected results:

The print result of the background image should be the same as the browser display and preview.

Regression Window:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c9510d6b10a41c473728ee7e25f6dc0fd8c66f6f&tochange=d8b66c3db77594a0e43de8f93fb925765767031c

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Printing: Output
Product: Firefox → Core
Attached image test-case.jpg —

Additional Information:

  • See test-case.html and test-case.jpg for detailed behavior.
  • The same result can be obtained by creating a PDF using "Microsoft Print to PDF".
  • However, using "Save to PDF" gives the same result as the preview.
Attached image jorudan.jpg —

This bug is occurring on the following website.

https://www.jorudan.co.jp/

See the attached jorudan.jpg.

Bug 1719215 looks the most suspicious one in the regression range.

Component: Printing: Output → Graphics
See Also: → 1719215

Testing with the current FF release (101.0), I can't reproduce this bug on macOS 10.15.7.

I currently don't have a way to test on Windows. Later I'll test on Linux.

Edit: In case it's relevant, I tested using "Save to PDF".

However, using "Save to PDF" gives the same result as the preview.

This is ambiguous. Are you saying the bug doesn't happen with "Save to PDF"?

Edit: I also don't see the bug (on macOS 10.15.7, in the print preview) when I choose to print to my Lexmark X363dn printer.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #5)

Testing with the current FF release (101.0), I can't reproduce this bug on macOS 10.15.7.

I currently don't have a way to test on Windows. Later I'll test on Linux.

Edit: In case it's relevant, I tested using "Save to PDF".

This bug only occurs on Windows.
The code seems to be separate on Linux and Windows.

OS: Unspecified → Windows

Then this bug might be fixed by doing a Windows-specific backout of my patch for bug 1719215. Sometime in the next couple of days I'll do a tryserver build of this, and post a link here for you to test with.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #7)

Then this bug might be fixed by doing a Windows-specific backout of my patch for bug 1719215. Sometime in the next couple of days I'll do a tryserver build of this, and post a link here for you to test with.

Thank you.
Once a test build is provided, I will use it to test and report the results.

This is ambiguous. Are you saying the bug doesn't happen with "Save to PDF"?

I first found the bug when I printed https://www.jorudan.co.jp/
On Windows, the image on that page is corrupted no matter which printer you use to print.
I have prepared test-case.html to explain the reproduction steps and symptoms in the bug report.
When printing test-case.html, only "save to PDF" output print results that look normal.
Does the size of the image affect the occurrence of bugs?

Does the size of the image affect the occurrence of bugs?

I don't know. Back when I was working on bug 1719215, I only found a few examples that triggered its crashes.

It's possible (likely, in fact) that bug 1719215 caused buffer overflows to happen on all platforms, though it only triggered crashes on macOS. So doing a Windows-specific backout would (at best) be an interim measure. For the moment, though, I just want to find out if it was my patch for bug 1719215 that triggered this bug.

Here are my tryserver builds:

https://treeherder.mozilla.org/jobs?repo=try&revision=26b4c13511b2a15f507d2d7c3c48d2bab6ec6f79

And here's what I think is the Windows 64bit installer. I say "I think" because I've actually never before done a Windows tryserver build.

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QC07rrKbTISydzxTIP8a8A/runs/0/artifacts/public/build/setup.exe

Let us know your results.

I downloaded and ran setup.exe, but it only expanded to the program folder:

Firefox Nightly\uninstall\shortcuts_log.ini
Firefox Nightly\uninstall.log
Firefox Nightly\install.log
Firefox Nightly\installation_telemetry.json

Or you can instead use target.zip in the "Artifact and Debugging tools" pane in https://treeherder.mozilla.org/jobs?repo=try&revision=26b4c13511b2a15f507d2d7c3c48d2bab6ec6f79&selectedTaskRun=QC07rrKbTISydzxTIP8a8A.0 . The zip contains all files, once after it's unzip-ed, then you can directly launch firefox.exe there I believe.

I ran target.installer.exe and the installation was successful.
I immediately printed test-case.html and https://www.jorudan.co.jp/ and was able to print normally.

Great! Thanks for quick checking!

Regressed by: 1719215
See Also: 1719215 →

Set release status flags based on info from the regressing bug 1719215

status-firefox101: --- → affected
status-firefox102: --- → affected
status-firefox103: --- → affected
status-firefox-esr91: --- → affected
Has Regression Range: --- → yes

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

Status: UNCONFIRMED → NEW
Ever confirmed: true

I just bought a copy of Windows 10 64bit and used it to create a VMware Fusion 12.1.2 VM (running on macOS 10.15.7). I can't reproduce this bug there (using the current FF release).

The easy way to fix this bug is to do a Windows-specific backout of my patch for bug 1719215. But, as I mentioned above in comment #9, this might open security holes in FF on Windows. The alternative (changing FF's Windows-specific printing code) would be much harder, at least for me. I know nothing about that code, and haven't done any Windows development in decades. This is made even more complicated by the fact that you're only able to reproduce this bug using "Microsoft Print to PDF".

Before we do anything more here, I think we need to find out exactly where and under what circumstances this bug happens. Which versions of Windows? Which default language settings? And so forth.

I tested with the en-US distro of Firefox on the English US version of Windows 10.

For what it's worth, setting Japanese as Windows' default language makes no difference to my results. Neither does using the Japanese distro of Firefox 101.0. I still can't reproduce this bug.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #18)

I just bought a copy of Windows 10 64bit and used it to create a VMware Fusion 12.1.2 VM (running on macOS 10.15.7). I can't reproduce this bug there (using the current FF release).

Is it possible to use a pure Windows 10 PC instead of virtualized Windows 10?

This is made even more complicated by the fact that you're only able to reproduce this bug using "Microsoft Print to PDF".

This bug can be reproduced on various printers. The only exception was when I printing test-case.html used "Save to PDF".

Before we do anything more here, I think we need to find out exactly where and under what circumstances this bug happens. Which versions of Windows? Which default language settings? And so forth.

OS: Windows 10 Pro 64-bit (10.0, Build 19043) (19041.vb_release.191206-1406)
Lang: Japanese (Regional Setting: Japanese)
Processor: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (4 CPUs), ~3.3GHz
Display Chip: Intel(R) HD Graphics Family

This bug was found in a topic posted on the MozillaZine.jp forum.
https://forums.mozillazine.jp/viewtopic.php?f=2&t=19716#p71815

Is it possible to use a pure Windows 10 PC instead of virtualized Windows 10?

Not for me. I haven't owned a Windows computer for decades.

But this is a legitimate question: Differences in OS behavior in a virtual machine (compared to on bare metal) are rare, but I've seen them myself with macOS on VMware Fusion. We need to get some Mozilla Windows developers involved here, both to find out how reproducible this bug is and to look for ways to fix it (other than by doing a Windows-specific backout of my patch for bug 1719215). I'll look for "blame" in the Windows-specific printing code, and CC here some of those who are still active.

We need to get Mozilla Windows developers involved here, both to find out how reproducible this bug is and to look for ways to fix it. I found your names in the "blame" for some Windows-specific printing code (on https://searchfox.org). I don't know if any of you can help here. But if not, I assume you know people who can. Thanks in advance!

Flags: needinfo?(jwatt)
Flags: needinfo?(jmathies)
Flags: needinfo?(emcdonough)

FWIW, I can reproduce the issue on my Thinkpad T460p which uses an English version of Window 10 Pro 19043.1706.

Blocks: gfx-triage
Flags: needinfo?(jwatt)
Flags: needinfo?(jmathies)
Flags: needinfo?(emcdonough)

Might be printing related, not sure. Regression range possibly points to image related changes.

I can repro this.

Severity: -- → S3
Flags: needinfo?(jmuizelaar)

This fixes subimage drawing with Cairo.

Assignee: nobody → jmuizelaar
Status: NEW → ASSIGNED
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34815 for changes under testing/web-platform/tests

https://hg.mozilla.org/mozilla-central/rev/e5a4787c5ac8

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox104: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
Upstream PR merged by moz-wptsync-bot
No longer blocks: gfx-triage
status-firefox-esr102: --- → affected
Flags: needinfo?(jmuizelaar) → in-testsuite+

Comment on attachment 9284363 [details]
Bug 1769429. Revert 1719215.

Beta/Release Uplift Approval Request

  • User impact if declined: Printing with subsetting background images will be wrong
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This just backs out a patch that was wrong.
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9284363 - Flags: approval-mozilla-beta?

Comment on attachment 9284363 [details]
Bug 1769429. Revert 1719215.

Approved for 103.0b9, thanks.

Attachment #9284363 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1778158

Comment on attachment 9284363 [details]
Bug 1769429. Revert 1719215.

Approved along with bug 1778158 for 102.2esr.

Attachment #9284363 - Flags: approval-mozilla-esr102+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: