Can't select "margins: none" when computed margins are also 0.
Categories
(Toolkit :: Printing, defect, P2)
Tracking
()
People
(Reporter: mbalfanz, Assigned: sfoster)
Details
(Whiteboard: [print2020_v82])
Attachments
(2 files)
On Windows, it's not possible for me to select the menu option "margins: none". It will always jump back to "minimal"
STR:
- visit for example https://blog.greenroots.info/10-lesser-known-web-apis-you-may-want-to-use-ckejv75cr012y70s158n85yhn
- open the print dialog
- 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•4 years ago
|
||
Does this happen for all the printers, or only one or two of them?
Reporter | ||
Comment 2•4 years ago
|
||
This happens for all my installed printers, virtual and physical.
Comment 3•4 years ago
|
||
Huh. Weird. 🙂
Comment 4•4 years ago
|
||
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…
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
The margins are computed for the current paper size.
- Open the print UI for any document
- Select "minimum" or "none" in the margins picker
- Open the browser console (ctrl+shift+J, or Main menu > Web developer > Browser Console)
- Enter into the console:
PrintUtils.getPreviewBrowser(gBrowser.selectedBrowser).closest(".dialogBox").querySelector(".dialogFrame").contentWindow.PrintEventHandler.viewSettings.currentPaper
- 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?
Assignee | ||
Comment 6•4 years ago
|
||
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•4 years ago
|
||
(Adding Erik to the Cc list as a head's up in case this turns out to be something up the stack… 😉)
Reporter | ||
Comment 8•4 years ago
|
||
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.
Reporter | ||
Comment 9•4 years ago
|
||
I just tried it again with a different printer, and there the result was as assumed unwriteableMargin*
all set to 0.
Comment 10•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
(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?
Assignee | ||
Comment 13•4 years ago
|
||
(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?
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 14•4 years ago
|
||
(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.
Assignee | ||
Comment 15•4 years ago
|
||
- 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•4 years ago
|
||
Comment 17•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 18•4 years ago
|
||
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.
Assignee | ||
Comment 19•4 years ago
|
||
(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•4 years ago
|
||
Thank you for the info. I did use different printers.
According to comment 18 and comment 19, I will mark this bug verified fixed.
Description
•