1662699 - Can't select "margins: none" when computed margins are also 0.

Status: VERIFIED FIXED

(Toolkit :: Printing, defect, P2)

Description

[Martin Balfanz [:mbalfanz]]

On Windows, it's not possible for me to select the menu option "margins: none". It will always jump back to "minimal"

STR:

1. visit for example https://blog.greenroots.info/10-lesser-known-web-apis-you-may-want-to-use-ckejv75cr012y70s158n85yhn
2. open the print dialog
3. try to set the margins to "none"

ER: setting should be accepted
AR: setting jumps back to "minimal", no matter if I select it via keyboard or mouse

Comment 1

[Blake Winton (:bwinton) (:☕️)]

Does this happen for all the printers, or only one or two of them?

Comment 2

[Martin Balfanz [:mbalfanz]]

This happens for all my installed printers, virtual and physical.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

Huh. Weird. 🙂

Comment 4

[Blake Winton (:bwinton) (:☕️)]

We think this is because the minimal margins are 0, so they'll be the same as "none". Per that, I'm setting this as P2/S4, but someone should reply with instructions on how we can verify that…

Comment 5

[Sam Foster [:sfoster] (he/him)]

The margins are computed for the current paper size.

1. Open the print UI for any document
2. Select "minimum" or "none" in the margins picker
3. Open the browser console (ctrl+shift+J, or Main menu > Web developer > Browser Console)
4. Enter into the console: PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings.currentPaper
5. Enter into the console:
   PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings.marginTop
PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings.marginRight
PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings.marginBottom
PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings.marginLeft

The result from step 4. is an object. If you expand that, you see values for the unwriteableMargin* properties. These are what we use for the "minimum" values. They are normally some < 0 value. My hypothesis is that they will be 0 when this bug reproduces

The results from step 5 are the computed values. They should match the unwriteableMargin values from step 4, when the "minimum" margins option is selected.

Martin, can you try this out and let me know what values you see?

Comment 6

[Sam Foster [:sfoster] (he/him)]

In the meantime, I'm putting together a patch to disable/hide margin options when they are redundant. So if all the margin presets compute to 0, we'll only show "None" and disable the picker. If the minimum and default compute to the same values, we'll only show "Default" (?)

There is the still question of what is going on if a printer's settings report 0 for its default margins as well as 0 for its unwriteable margins. That would seem to suggest a possible error somewhere up the stack.

Comment 7

[Blake Winton (:bwinton) (:☕️)]

(Adding Erik to the Cc list as a head's up in case this turns out to be something up the stack… 😉)

Comment 8

[Martin Balfanz [:mbalfanz]]

Attachment: object.txt

The result of step 4 gives undefined. The results of step 5 give 0 for each of them.

See attached the results if I run PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings. Maybe that helps.

Comment 9

[Martin Balfanz [:mbalfanz]]

I just tried it again with a different printer, and there the result was as assumed unwriteableMargin* all set to 0.

Comment 10

[Blake Winton (:bwinton) (:☕️)]

Nice! That's what we were hoping, so Sam's patch should handle it. 🙂

I'm not sure if Erik wants to do some digging to try and figure out why all your margins are set to 0… (Probably after we're done working on 81.)

Comment 11

[Erik Nordin [:nordzilla]]

I think Bob Owen would be a better person to look into this on the Windows side of the code, though I'm happy to take a look. I'm going to also cc Bob.

Comment 12

[Jonathan Watt [:jwatt]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #6)

In the meantime, I'm putting together a patch to disable/hide margin options when they are redundant. So if all the margin presets compute to 0, we'll only show "None" and disable the picker. If the minimum and default compute to the same values, we'll only show "Default" (?)

Putting my user hat on, personally I really dislike and find it frustrating when options inexplicably (from the user's point of view) appear and disappear like this, and I've heard other people complain about such behavior in the past. It's certainly not my call, but wouldn't it be less irksome/more clear to users to keep both options and have them do the same thing?

Comment 13

[Sam Foster [:sfoster] (he/him)]

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

Putting my user hat on, personally I really dislike and find it frustrating when options inexplicably (from the user's point of view) appear and disappear like this, and I've heard other people complain about such behavior in the past. It's certainly not my call, but wouldn't it be less irksome/more clear to users to keep both options and have them do the same thing?

I have a working WIP patch for this and I can go either way. I'm blocked on a UX decision. :shorlander, let me know if you need more context or anything?

Comment 14

[Stephen Horlander [:shorlander]]

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

(In reply to Sam Foster [:sfoster] (he/him) from comment #6)

In the meantime, I'm putting together a patch to disable/hide margin options when they are redundant. So if all the margin presets compute to 0, we'll only show "None" and disable the picker. If the minimum and default compute to the same values, we'll only show "Default" (?)

Putting my user hat on, personally I really dislike and find it frustrating when options inexplicably (from the user's point of view) appear and disappear like this, and I've heard other people complain about such behavior in the past. It's certainly not my call, but wouldn't it be less irksome/more clear to users to keep both options and have them do the same thing?

I don't think there's necessarily a right answer here WRT to solving confusion. If we leave it and it doesn't do what people expect (i.e. no visual change between the two options) that's also confusing. If we leave the list in tact but disable one of the options that

I'd recommend not showing one of the options if they do the exact same thing. Unless I am missing something in this bug it sounds like this will be specific to the printer? So it will at least be consistent with only showing options that the printer supports.

Comment 15

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1662699 - Disable margin options when they are redundant. r?emalysz

• Default margins should always be at least the unwriteable margins
• Hide redundant options - ie. they represent the same set of values as a previous option, evaluated in the order "none", "default", "minimum"

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fb93cc958f9a
Disable margin options when they are redundant. r=emalysz

Comment 17

[Bogdan Tara[:bogdan_tara | bogdant]]

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

Comment 18

[Oana Botisan, Desktop QA]

I managed to reproduce the issue on an older version of Nightly.

On Windows 10 x64 and Ubuntu 18.04 x64 using Nightly 83.0a1 and Firefox 82.0b2 the "Minimum" option is not displayed anymore.

However on macOS 10.13 the option is still displayed (but the value for unwriteableMargin is > 0). I used the site from comment 0 to verify this issue.

Is this expected behaviour? To me it seems like an inconsistent behaviour across platforms, especially because on Windows and Ubuntu it doesn't register that there is a margin like on macOS.

Comment 19

[Sam Foster [:sfoster] (he/him)]

(In reply to Oana Botisan, Desktop Release QA from comment #18)

I managed to reproduce the issue on an older version of Nightly.

On Windows 10 x64 and Ubuntu 18.04 x64 using Nightly 83.0a1 and Firefox 82.0b2 the "Minimum" option is not displayed anymore.

However on macOS 10.13 the option is still displayed (but the value for unwriteableMargin is > 0). I used the site from comment 0 to verify this issue.

Is this expected behaviour? To me it seems like an inconsistent behaviour across platforms, especially because on Windows and Ubuntu it doesn't register that there is a margin like on macOS.

If the unwriteableMargin is > 0, then the margin picker is correctly showing the "minimum" option, so this is expected.
Assuming you are using the same printer with all the platform, I would guess different printer drivers are providing different values there.

Comment 20

[Oana Botisan, Desktop QA]

Thank you for the info. I did use different printers.
According to comment 18 and comment 19, I will mark this bug verified fixed.