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

Steps to reproduce:

Selected Print, selected HP 4 Plus printer, viewed results - all blank pages

Actual results:

Correct number of pages shown, but all are blank.

Does NOT work on clean profile (reset)
Does work in Safe mode
Does work on adobe pdf printer

Old print preview works OK (print. tab_modal. enabled option to false)

Expected results:

Print preview should have shown page contents

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

Which file were you printing? Was it a PDF file out of curiosity? If so suspect this is a dupe of bug 1663140.

And, if so, does it work if you use Ctrl+P rather than the print button of the PDF viewer? Thanks

Just a straight web page print. File==>Print.

Also tried Ctrl+P, same results.

Tried many different web pages, among them were Google search results and about:config, all with the same results - blank pages.

[Tracking Requested - why for this release]: Printing to some physical printers on Windows doesn't work at all with the new print dialog.

Ugh, ok, that sounds really bad, thanks so much for filing. Does the print preview in the tab-modal dialog show up properly? I assume so, but just double-checking.

Also, do you know if this happened in previous betas? Given this seems printer-specific, if you could use mozregression to narrow down when this broke (or if it ever worked with the new print dialog), it'd be awesome. Alternatively, can you paste which printer is this so that we can try to reproduce it somehow?

Emil, do you know if QA can reproduce something like this?

Oh wait, I may have misunderstood, the preview is blank, only when you select that printer right?

I'd be curious if actually printing to the physical printer works with the old and new UI.

Preview does not work (blank pages)

Actual printing is OK

Additionally, this printer is network connected (IP). Other USB printers do not have this problem.

Additionally, this is on Windows 7.

Additionally, this is on Windows 7.

It's worth noting that QA hasn't been performing test runs on Win 7 with the new UI.

Bob: Were you testing Win 7 much as part of your work?

81.0b7 fixes the problem for me. To verify I downgraded to b6, which failed and then let it update to b7, which worked.

Redirecting the ni? to Anca. She will have access to Windows 7 & to a network connected printer (tomorrow).

(In reply to Sean Voisen (:svoisen) from comment #9)

Additionally, this is on Windows 7.

It's worth noting that QA hasn't been performing test runs on Win 7 with the new UI.

In my opinion we should be prioritising Windows 7 above everything else (apart from Windows 10) for testing, particularly printing testing.
According to our stats Win 10 usage stands at 56.7 %, Win 7 - 24.2 %, Win 8.1 - 5.1 % and then macOS Catalina - 2.8 %.
I suspect this is even more important for printing, because this may be an under report for business environments, where I suspect printing might be more frequent.

Bob: Were you testing Win 7 much as part of your work?

No.
I held onto my old Windows 7 Mozilla desktop for as long as I could for this very purpose, because nearly everyone else (of an already small proportion at Mozilla) was on Windows 10.
I've just tried a machine of my own that still has Win 7 with Fx81.0b6, the preview was fine and this was for a Wi-Fi connected printer.
So might not by a Win 7 issue or not just Win 7.

Paul - do you have any Windows 10 machines that you can test with this printer?
Also, does the old Print Preview work? - File->Print Preview

By "HP 4 Plus", I guess this is an HP LaserJet 4 Plus, which from what I can see is over 25 years old, so I wonder if this could be a driver issue and we're using a function that isn't implemented properly.
The only thing I can think that might be different is we are now using DeviceCapabilities to return paper sizes in some cases, although I'm not sure whether those get back into the settings.

Sam - Also possibly totally unrelated, but should this be dividing? (according to the comment above):
https://searchfox.org/mozilla-central/rev/ac142717cc067d875e83e4b1316f004f6e063a46/toolkit/components/printing/content/print.js#695

Ah, I did use the size from DeviceCapabilities here:
https://searchfox.org/mozilla-central/source/widget/windows/nsPrinterWin.cpp#65

I had to look up the name and so just used the size from that list as well.
This didn't actually get used in the new front end until Beta 6.

Paul - would it also be possible for you to test 81.0b5 from here:
https://archive.mozilla.org/pub/firefox/releases/81.0b5/win64/en-US/

If you need a different locale then just go up a directory.
Thanks.

Reply to comment #12:
Beta 5 WORKS on Windows 10.
Old print preview WORKS on beta5, but only if print.tab_modal.enabled is set to false (otherwise menu item is not present)

Reply to comment #13:
Test of 81.0b5 from indicated location FAILS.

Additional:
Beta 7 has the preference set to False by default (but you knew that)
Beta 7 WORKS on Windows 7.

Also:
Print to PDF has issues: magnification and occasional, random error message.

The lack of custom margins is missed.

I've tried installing the HP LaserJet 4 Plus printer driver on my Windows 7 machine and the new print preview seems to be fine.
I can only do this as a locally attached printer, so doesn't quite replicate the circumstances.

Hiro, this has only been "fixed in 81.0b7" by virtue of the pref having automatically switched to false as of b7. Since this bug is explicitly about the new UI, I think having "fixed in 81.0b7" in the title would be misleading/confusing.

Oop, gosh. I didn't notice that print.tab_modal.enabled is @IS_EARLY_BETA_OR_EARLIER@..

I didn’t run into this particular issue (only bug 1663140 - before fix and bug 1663639) while testing with Fx 81.0b6/ Fx 81.0b7/ Fx 81.0b8 and Fx 82.0a1 (2020-09-08/ 2020-09-09) on Windows 7 using a network connected printer, Kyocera ECOSYS P2135dn (the only available on my side), both with the old and the new UI.

Sam - Also possibly totally unrelated, but should this be dividing? (according to the comment above):
https://searchfox.org/mozilla-central/rev/ac142717cc067d875e83e4b1316f004f6e063a46/toolkit/components/printing/content/print.js#695

I think its correct? The margin values we get are in points, but we need to calculate a settings value in the unit specified by the printer settings. In this case, it is inches; INCHES_PER_POINT is 1/72 (72 pts per inch), if the margins were 1" margin.top would be 72, multiplying 72 by INCHES_PER_POINT gets us the 1.0 we expect.

(In reply to Paul Allen from comment #0)

Does NOT work on clean profile (reset)
Does work in Safe mode

This is very curious. Safe mode, as far as I know, disables Add-Ons, starts with a clean set of prefs, disables user style sheets, disables some JavaScript optimizations and disables some hardware acceleration. A clean profile should be broadly the same, for the things that matter to printing at least. So I'm wondering if your Windows 7 machine(s) have some app installed that auto-installs a Firefox Add-on that either sets some prefs or affects things in some other way.

Using a clean Firefox profile (checking that the problem still persists), could you open the page about:support, click the "Copy text to clipboard" button, and then save that to a file and attach it here. NOTE: please do check through the contents of this file first to make sure you're happy to attach it to this public bug. I don't think it should contain anything private, but all sorts of things are stored in preferences.

Actually, it's probably first worth retesting with Nightly Firefox (from here or here) to verify whether any of our recent changes have fixed this issue. If they haven't, then you can still use that Nightly to carry out the steps above to get the most up to date/relevant info.

Additional info:
With 82.0A1 nightly, Epson WF-3640 (Fax) also fails in the same way as HP-4 Plus - blank pages. Also works in SAFE mode.
This is a USB attached printer.
The Epson has another interface, (non-Fax, normal printing) that works OK.

I also have the troubleshooting info in safe mode and a compare of the normal/safe mode if you want it.

Thanks, Paul. Yes please. :-)

Thanks again, Paul. Can you open the page about:config and see if setting any of the following (one at a time, then maybe both) gets things working:

• gfx.webrender.force-disabled = true
• layers.gpu-process.enabled = false

I don't think these prefs are live, so you'll need to restart Firefox after each pref flip before testing to see if it makes a difference.

Either of them and both of them fixes the problem on both printers.

Interesting, we're getting somewhere, thanks. :-)

(In reply to Paul Allen from comment #15)

Also:
Print to PDF has issues: magnification and occasional, random error message.

Just to confirm, in the list of available destinations that you can select, in addition to the HP 4 Plus and adobe pdf printer, you should also have "Save to PDF". When you say "Print to PDF" presumably you mean this option, and you're saying that the preview is no longer blank if you switch to this destination, but that it does have scaling issues?

The lack of custom margins is missed.

For now I think you can provide custom margins via the "Print using system dialog..." link above the "Print" button (at least you can on macOS). Bug 1664570 tracks adding that functionality to the new print preview interface.

(In reply to Jonathan Watt [:jwatt] from comment #31)

Just to confirm, in the list of available destinations that you can select, in addition to the HP 4 Plus and adobe pdf printer, you should also have "Save to PDF". When you say "Print to PDF" presumably you mean this option, and you're saying that the preview is no longer blank if you switch to this destination, but that it does have scaling issues?

Not a problem any more. Beta 5 did have this issue, the Nightly seems to be fine.

The lack of custom margins is missed.

For now I think you can provide custom margins via the "Print using system dialog..." link above the "Print" button (at least you can on macOS). Bug 1664570 tracks adding that functionality to the new print preview interface.

Not in Windows 7, at least.
"Print to PDF" is not available at all in the system dialog.
For other printers "Margins" is not one of the available properties.

(In reply to Paul Allen from comment #32)

Not a problem any more. Beta 5 did have this issue, the Nightly seems to be fine.

Ah, right. Fixed by bug 1659527, I assume.

Not in Windows 7, at least.
"Print to PDF" is not available at all in the system dialog.
For other printers "Margins" is not one of the available properties.

Ugh, that's a problem. Or it would seem to raise the priority of bug 1664570 at least.

(In reply to Paul Allen from comment #30)

Either of them and both of them fixes the problem on both printers.

Bob, do you have any ideas how having a specific printer selected could result in our GFX code getting upset with our print preview document on Windows?

Hi Jim: Per comment 29, do you think you can get someone to help us investigate why WebRender could be causing blank pages in our new print preview? This is one of our higher priority bugs for the new print UI.

I've sorta, kinda reproduced this on a win7 machine. First, I opened:

Control Panel -> Hardware and Sound -> Devices and Printers -> Add a printer -> Add a network, wireless or Bluetooth printer

Then I selected the Brother printer connected on my network (not at that time installed on the Windows 7 machine) and clicked Next. The next screen asked me to install a printer driver, but instead of installing the Brother driver matching my printer (actually there wasn't a matching driver listed anyway) I selected "HP Laserjet 2200 Series PCL 5" and proceeded to install that.

Switching back to Nighly and trying to print I then had "HP LaserJet 2200 Series PCL 5" in the list of available printers. Selecting that gave me two blank pages in print preview, and printing it printed two pages with the actual contents that should have been displayed in the preview from my Brother printer.

As was the case for Paul in comment 30, setting gfx.webrender.force-disabled = true gets the print preview rendering correctly too.

I'm not up to speed in any way on WebRender, so if someone from GFX can repro and debug that would be a huge help. Either that, or a bit of hand-holding. :-) It's going to take me the best part of a day to get a working build/debug environment up and running on this old win7 machine though. I can at a minimum sanity check the page sizes etc. once I've done that.

Fails in B&W, works in color.

With the Nightly, every printer I select, including Adobe DC, works if Color is selected (where possible) and fails (blank print preview) if B&W is selected

Jonathan, does removing this css rule make the preview display correctly?

That's the only thing that comes to mind like it could cause it given the description... should help to isolate the problem at least.

Quoting from Glenn on Matrix:

(1) Take a WR capture (ctrl-shift-3) with it working (different printer driver?) and with it not working, and do a diff on the scene.ron capture file. That may offer some clues.
(2) Take a WR capture and send it to me to try and repro locally. The WR capture files are mostly portable between machines, but can be a bit fragile.

If you can post the capture scene.ron files for a working / non-working test case, I will take a look at the diffs as they may offer some clues.

(In reply to Jonathan Watt [:jwatt] from comment #34)

(In reply to Paul Allen from comment #30)

Either of them and both of them fixes the problem on both printers.

Bob, do you have any ideas how having a specific printer selected could result in our GFX code getting upset with our print preview document on Windows?

The only thing I could think of originally was the page size being wrong.
I can't think why that would interfere with webrender/acceleration and not without it.
I wonder if we're getting really big surfaces and we're hitting a Direct2D/3D limit.

(In reply to Paul Allen from comment #37)

Fails in B&W, works in color.

Ah, I see the same. That makes sense now.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #38)

Jonathan, does removing this css rule make the preview display correctly?

Yup. So it looks like WebRender doesn't support filters (at least the grayscale filter) on our Windows 7 machines.

Does that reproduce with regular web content? Like idk, just doing document.body.style.filter = "grayscale(1)" in the console on this page?

Yup.

Re-titling this bug given that we now have a better diagnosis of the issue (comment 42).

I see Glenn jumped into help so will clear the ni? on Jim.

This reproduces on just data:text/html,<p style="filter:grayscale(1)">hi - that's blank, but if I change it to grayscale(0) then "hi" is shown. In that case I don't think the .ron files are useful but I'll attach them all the same.

Since this appears to be on a configuration that will be difficult for me to reproduce locally, we're going to try a series of tests that might offer some clues to what is occurring.

1. We know that grayscale(0) is working, and grayscale(1) isn't. But WR recognizes that grayscale(0) is a no-op, and skips drawing the filter entirely. Could you test what the output is like with filter values of 0.5, 0.001, 0.01 and 0.99 - do all of those result in no output at all?

2. For the following tests, you'll need to edit the brush_blend.glsl shader, build Gecko, and then run the test case.

2a) What is the result if you set the color matrix to identity by changing [1] to vColorMat = mat4(1.0);

2b) What is the result if you comment out the entirety of the fragment shader in [2], and change that function to be return Fragment(vec4(1.0, 0.0, 0.0, 0.5));. Does that show up a red tinted primitive with the expected position and size?

Once we know the answer to those, we'll work out next steps.

[1] https://searchfox.org/mozilla-central/source/gfx/wr/webrender/res/brush_blend.glsl#119
[2] https://searchfox.org/mozilla-central/source/gfx/wr/webrender/res/brush_blend.glsl#271

(In reply to Glenn Watson [:gw] from comment #51)

Could you test what the output is like with filter values of 0.5, 0.001, 0.01 and 0.99

These all result in the same broken rendering (nothing rendered) as 1.

2a) What is the result if you set the color matrix to identity by changing [1] to vColorMat = mat4(1.0);

I had to make that mat4(vec4(1.0, 0.0, 0.0, 0.0), vec4(0.0, 1.0, 0.0, 0.0), vec4(0.0, 0.0, 1.0, 0.0), vec4(0.0, 0.0, 0.0, 1.0)).

[Edited] No difference, the filtered content still fails to render.

Paul, could you tell me what it says for "target" on the page about:buildconfig?

(In reply to Glenn Watson [:gw] from comment #51)

2b) What is the result if you comment out the entirety of the fragment shader in [2], and change that function to be return Fragment(vec4(1.0, 0.0, 0.0, 0.5));. Does that show up a red tinted primitive with the expected position and size?

Yes, a pinkish rectangle where the filtered content should be.

Build platform
target
x86_64-pc-mingw32

One other test Glen asked me to do: changing the default case at https://searchfox.org/mozilla-central/source/gfx/wr/webrender/res/brush_blend.glsl#309 to color = vec3(1.0, 1.0, 0.0); alpha = 0.5;. That results in a yellow rectangle where the filtered content should be.

Jeff, I suspect this is a driver bug - the two machines it repros on are HD3000 GPUs. One of them has an old driver, one of them has the most up to date driver (which is still ~5 years old).

Do you have any hardware available with an HD3000 GPU to do some experiments with the shader to see if we can find a workaround?

As an extra data point, I cannot reproduce on my win7 machine (even with WebRender forced on).
build target: x86_64-pc-mingw32
GPU: Intel(R) HD Graphics 4400

I can reproduce this on Win10 on my (gen6) HD 2000 with driver version 9.17.10.4459

Running with unoptimized shaders fixes this for me.

I tried disabling all of the individual optimizations in glslopt but the shaders generated in that case don't compile. I needed to keep on inlining and dead_code_elimination. However, having just the optimizations was sufficient to reproduce the problem. I suspect it's the inlining that's causing a miscompilation somewhere down the line.

Jamie, can you look at why disabling inlining makes brush_blend uncompilable?

In case it helps, I made the brush shaders a whole lot more complicated a little while ago in order to support generating a "multi-brush" shader that supports all of the brush shaders in a single one for batching purposes. Since then other things have sort of made this multi-brush work obsolete so we can roll some of it back and simplify a bunch of stuff (for example the way varyings and some function declarations are aliased using #defines).

(In reply to Jeff Muizelaar [:jrmuizel] from comment #61)

I tried disabling all of the individual optimizations in glslopt but the shaders generated in that case don't compile. I needed to keep on inlining and dead_code_elimination. However, having just the optimizations was sufficient to reproduce the problem. I suspect it's the inlining that's causing a miscompilation somewhere down the line.

Jamie, can you look at why disabling inlining makes brush_blend uncompilable?

I'll look in to this. My guess would be it assumes functions will be inlined so makes no attempt to forward declare them, or something.

In the meantime, we can easily land a webrender patch to choose the unoptimized brush_blend source at runtime on affected platforms. Should buy us a bit more time to figure out what the problem is?

My guess would be it assumes functions will be inlined so makes no attempt to forward declare them, or something.

This was indeed one of the reasons, but also it outputs quite a lot of void tmpvar; declarations (which the dead code elimination might remove)? And uses tmpvars for the offset argument to texelFetchOffset, when that is required to be a constant. Maybe inlining probably fixes that.

I can try to make the optimizer work around these if that would be useful. Alternatively I can attach the output shaders which I've manually made those fixes to. Unfortunately I can't reproduce the bug on my hardware to investigate any further.

(In reply to Nicolas Silva [:nical] from comment #62)

In case it helps, I made the brush shaders a whole lot more complicated a little while ago in order to support generating a "multi-brush" shader that supports all of the brush shaders in a single one for batching purposes. Since then other things have sort of made this multi-brush work obsolete so we can roll some of it back and simplify a bunch of stuff (for example the way varyings and some function declarations are aliased using #defines).

If you put a patch together for this I can try it.

(In reply to Jamie Nicol [:jnicol] from comment #64)

I can try to make the optimizer work around these if that would be useful. Alternatively I can attach the output shaders which I've manually made those fixes to. Unfortunately I can't reproduce the bug on my hardware to investigate any further.

Yeah, attach them and I'll try them out.

optimized shaders with compilation errors manually fixed

It looks like the driver bug is triggered by flattening the switch statement in brush_blend_ALPHA_PASS.vert to an if chain

But if I convert the if chain to an if else chain it seems to work fine. Changing the switch to an if else chain seems to be sufficient to fix the problem.

glslopt doesn't support switch statements in its IR so they get lowered
to a collection of if statements. It seems like there's a driver
bug on Intel gen6 that can cause this if chain to be miscompiled. If we
manually lower the switch to an 'if else chain' it seems to avoid the
problem.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e25b0b4a7a8284a4a625e377ab50186608cf6a7d

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

Can we uplift this to Beta, so we don't have to worry about print preview's being blank during the printing experiment if nothing else?

Comment on attachment 9177433 [details]
Bug 1663344. Lower switch to if else chain.

Beta/Release Uplift Approval Request

• User impact if declined: filter: grayscale(1) doesn't work with WebRender on Intel gen6. Most noticeably this prevents print preview from working.
• Is this code covered by automated tests?: No
• 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 is just a reorganizing of the shader code to work around a shader compiler bug in the intel driver it should have no functional change otherwise.
• String changes made/needed:

(In reply to Jonathan Watt [:jwatt] from comment #75)

Can we uplift this to Beta, so we don't have to worry about print preview's being blank during the printing experiment if nothing else?

Yep. Can you confirm that the problem is fixed for you in Nightly?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #77)

Yep. Can you confirm that the problem is fixed for you in Nightly?

It certainly does. Many thanks, GFX folks. :-)

And thanks for reporting this, Paul!

Jeff points out this is a general WebRender issue affecting anything using the filter in question.

Comment on attachment 9177433 [details]
Bug 1663344. Lower switch to if else chain.

working around a driver bug; approved for 82.0b4

https://hg.mozilla.org/releases/mozilla-beta/rev/840bc4e62d9a