1756169 - Print button disabled for Dymo Printer

Status: RESOLVED FIXED

(Toolkit :: Printing, defect, P2)

Description

[Jason]

Attachment: 2022-02-18 09 31 37.png

Steps to reproduce:

Printing anything to the Dymo Label Printer using the modal printing gui.
(print.tab_modal.enabled = true)
Typically the printed content webpage will be formatted to fit the label, but I found printing anything till trigger the problem.
This issue didn't exist with 84.0.2, and started from 85 till the current latest 97.0.1 (where latest Firefox have no option to disable the modal print gui anymore)
I tested this using FireFox Portable, so the settings should be fairly stock.

Actual results:

The print button will be disabled, along with all the other print options, only the margins dropdown is enabled.

Expected results:

The print button should be enabled, and allows for printing.
If using the system dialog for printing, there is no issue with disabled print button, and the content gets sent to the Dymo Printer without any issues.

Comment 1

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

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

Comment 2

[Jason]

Some new discovery.
FF84, even though the print button is enabled, clicking it doesn't do anything.
The printing doesn't happen.
FF83, is the last version that worked with the print modal gui and actually prints.

Comment 3

[Mark Striemer [:mstriemer]]

Bob, this looks like it might be some configuration problem on Windows. Any ideas?

Comment 4

[Jason]

I've seen this problem on two of my computer, as well as on one of my client's computer as well.
All the other printers are fine, just when selecting the Dymo, then everything's disabled.

Comment 5

[Jason]

(In reply to Mark Striemer [:mstriemer] from comment #3)

Bob, this looks like it might be some configuration problem on Windows. Any ideas?

Going on this thought, I've installed another printer driver of another brand's label printer.
And it does work, printed to the same label size, without the disabled Print button.
So I'm sure it's not the issue of the paper size or the print content.

Perhaps something with the driver, but fact that it worked in older versions does mean something was changed in Firefox making this not work anymore.

Comment 6

[jscher2000]

Not sure whether this is relevant but here is my thought:

If the printer works with one driver but not another, it suggests that the results when Firefox getting the settings from Windows might differ depending on the driver. That seems strange, but could provide a clue. I believe it is possible to "see" what Firefox fetches from Windows when populating the setup panel using something this in the Browser Console (after enabling the command line):

var psettings = PrintUtils.getPrintSettings('DYMO LabelWriter 450', true);
console.log(psettings);

(It is slow for me on the first inquiry.)

Lacking a more efficient approach, I would compare all the properties that start with k to see whether any is out-of-bounds and could cause rendering to halt.

Comment 7

[Jason]

Alright, thanks to those clues and tips above, I've found the issue.
It's the calculation of the margins, and those numbers exceeding the paper size.
The default Firefox 0.5" margins, will be larger than the paper size for slimmer label sizes like the 30252 (FF margins + printer hardware limitation margins).

While logically this makes sense to disable the print button, I think the GUI needs some tweak to make this print issue obvious to the user, and also the margins section's gui is bugged.

So by default the margins will be set to "Default", changing the dropdown to Minimum or None will not do anything and switches back to Default.
It's not until you open up Custom, then you see the problem of the margin exceeding the paper size (with the textbox in red). Also the error message of "Please enter a valid margin for the selected paper size" doesn't show up until I manually re-enter the invalid 0.5.
These two should be shown to the user on first opening the print dialog.
Also, because of this "hidden away" error message, other controls on the print dialog also isn't operating, possibly because it is waiting for the user to fix this margin issue first.

Mozilla, please resolve this gui issue.
Thanks all.

Comment 8

[Mark Striemer [:mstriemer]]

I think we can likely write a test case for this. By setting margins that are too big for the page then the margins get reset to the "Default" setting, but if the paper size is smaller than those margins we'll hit this error.

Dealing with that though is a bit open ended though. I'm not sure if the error message is shown in this case, or we assume "Default" is a safe value and don't show the error. Either way, it should be shown. In addition to that we need to make it clear that there's an error, either by scrolling the field with an error into view when the dialog opens or showing the error message in some other place. Potentially we could show "1 error" where the pages per sheet is shown in the top right.

Comment 9

[Mark Striemer [:mstriemer]]

Looking at bug 1679535 it seems to show a similar issue where the margins dropdown is enabled but no error message is shown.

Comment 10

[Jason]

Wow, seems this hidden error issue has been around for a while and never fixed because that other bug points to an erroneous paper size selection.
Hopefully this will get fixed, as I'm printing a proper label size paper size.

Interestingly, looking at Chrome, when I select different paper size, the margin numbers changes as well. Perhaps the margin values are dynamic and calculated on Chrome, but static in Firefox. Not that there's anything wrong with having the static margin value.

But as you said, just need a proper way to show the error to the user, then this should be resolved. My initial issue was not knowing that it was a margin issue, thinking it was a printer compatibility issue, so I got sent to a wild goose chase, until narrowing down to the margin as the culprit.

Comment 11

[Mark Striemer [:mstriemer]]

I think we reset the margins to "Default" if they are determined to be invalid for the paper size, but it's possible that "Default" is also invalid. In that case we should show an error message or instead set them to "None". "None" might be preferred since this is likely a label maker if it's that small.

Comment 12

[Jason]

That should do the trick.
Show error, or set to none.

For now I've hard set the margins to 0 in about:config for the label printer, so I won't need to worry about the gui issue.

Comment 13

[Hanna Jones [:hjones]]

Attachment: Bug 1756169 - Set print margins to 'None' when defaults are invalid r=mstriemer

For smaller paper sizes (e.g. label maker sized paper) it's possible that the defaut margins will be too large, wich results in non-obvious error state for the print dialog. In this case we want to fall back to using "None" margins to ensure the form is valid/printing is still possible.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d80fc20863e
Set print margins to 'None' when defaults are invalid r=mstriemer

Comment 15

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/4d80fc20863e