1147229 - Background images with negative background-position x are incorrectly printed

Status: NEW

(Core :: Printing: Output, defect)

Description

[coq]

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; ASU2JS)

Steps to reproduce:

1) Create html page with only
<div style="height:20px; background:url(Test.gif) -1000px 0px no-repeat;"></div>
2) Test.gif is e.g. 2000px wide, 20px high image
3) Print it to printer or to PDF


Actual results:

The background image in the tag is shifted right (e.g. by 80px, depending probably on the tag width) - it means there is XXpx empty space on the tag left side.


Expected results:

The image should be printed as it is shown on the html page.

Comment 1

[Alice0775 White]

Could you attach a test case or a public url to reproduce the problem?

Comment 2

[coq]

The page is just the <div> and the .gif image, can be tested here:
http://www.treegrid.com/test/MozillaBug1147229/Print.html
and press Ctrl+P to print it

Comment 3

[Alice0775 White]

[Tracking Requested - why for this release]: Regression since Firefox35.

Comment 4

[Alice0775 White]

I can reproduce the problem on Windows7 with/without HWA.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=80164e15bd54&tochange=c232720a2847

Regressed by: Bug 1062723

Comment 5

[Alice0775 White]

Via local build:
Last Good: 5cae10117cf6
First Bad: c232720a2847

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Regression, tracking.
However, at we shipped 2 releases without getting a bug report sooner, not sure we will block the release for this.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Matt, do you think you will be able to help during the 38 beta cycle? Thanks

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 40 as well since it is likely affected.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Jet, could you find someone to help us on this? Thanks

Comment 10

[Jet Villegas (inactive)]

Attachment: Print output from Firefox, Chrome & IE on Windows

Attached is the print output from our color printer using the 3 browsers I have available on Windows 7 using the test supplied in comment 2. Note that none of the browsers print the background image as described in the bug. 

Am I missing a key step here?

Comment 11

[Alice0775 White]

(In reply to Jet Villegas (:jet) from comment #10)
> Created attachment 8596095 [details]
> Print output from Firefox, Chrome & IE on Windows
> 
> Attached is the print output from our color printer using the 3 browsers I
> have available on Windows 7 using the test supplied in comment 2. Note that
> none of the browsers print the background image as described in the bug. 
> 
> Am I missing a key step here?

You should turn on "Print Background(colors & images)" from Alt > File > Page Setup

Comment 12

[Jet Villegas (inactive)]

OK, I was able to see the difference in Print Preview, but the paper output still shows the blank image (same as in my earlier test.) Is that a known bug?

Comment 13

[Alice0775 White]

(In reply to Jet Villegas (:jet) from comment #12)
> OK, I was able to see the difference in Print Preview, but the paper output
> still shows the blank image (same as in my earlier test.) Is that a known
> bug?

Maybe your print driver does not support background image.

I can reproduce this problem with "Canon Bubble-Jet BJ M40" and "Bullzip PDF Printer" at least.

Comment 14

[Jet Villegas (inactive)]

I was able to reproduce the bug on Firefox 38, but Nightly 40 has the blank background images issue I described, even when "Print Background(colors & images)" is checked. That seems like a more serious and recent regression. I filed bug 1157542 for that.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Jet, as you can reproduce it, do you think you can help? Thanks

Comment 16

[Jet Villegas (inactive)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> Jet, as you can reproduce it, do you think you can help? Thanks

Seth will have a look as he checks out bug 1157542.

Comment 17

[ricardo]

The browser does not print the pictures set as background in the documents. This solution set such improvement via print setting is far from reasonable. Imagine an enterprise solution where some documents are impressions for approval but are not attested to the production environment?

The programodores can not be conditioned to a user action. After all, what's the problem to implement this feature?

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Too late for 38. It would be nice to have a fix ready for 39.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like other fixes may have improved this issue but it's still happening. 

This may also miss 39 but I would still take a patch if it verifies ok on nightly and aurora.

Comment 20

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for 39 now. Let's make sure this is still affecting 40 and 41. I can't bring myself to drop tracking for this yet.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Seth, do you think we should still track it? It seems we won't be fixing this anytime soon. Thanks

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Jet, do you know who could help us on this? Thanks

Comment 23

[Daniel Holbert [:dholbert]]

I can't reproduce this on Linux, FWIW. (printing URL from comment 2 to PDF, having ticked "Print Background Images" in print dialog's options) I tried Nightly (version 42), as well as release versions 37 and 38.

The left edge of the printed div looks just like my browser window -- there's no empty space between the border and the background-image.

So this might be Windows-only?  (At first I was thinking it might've just been fixed elsewhere, except that I can't reproduce it in older Firefox versions which are marked as affected per comment 3.)

Comment 24

[Lawrence Mandel [:lmandel] (use needinfo)]

This bug is now wontfix for 40. We're going to need to prioritize this and find an owner if it's going to be fixed in 41.

Comment 25

[Seth Fowler [:seth] [:s2h]]

I'll go ahead and take this during my next pass over regressions, coming soon.

Comment 26

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jet, Beta41 is already in it's final week(s). If we want this fixed for FF41, we might want to find an alternate owner. What do you think?

Comment 27

[Jet Villegas (inactive)]

(In reply to Ritu Kothari (:ritu) from comment #26)
> Jet, Beta41 is already in it's final week(s). If we want this fixed for
> FF41, we might want to find an alternate owner. What do you think?

No, this bug's severity here doesn't warrant a late fix. Bug 1157542 is the one I was most concerned about. Please untrack this one.

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

It's not ideal that we are wontfix'ing this bug for a few releases already. In any case, I am moved the tracking fwd from 41 -> 42 with the hope that this issue is fixed in the 42 release cycle.

Comment 29

[Sylvestre Ledru [:Sylvestre]]

We started to track it 5 months ago. I will just stop tracking it for now.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on inactive users to the triage owner.
:jwatt, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.