Affected versions

• 83.0a1 (2020-10-01)
• 82.0b6

Affected platforms

• Ubuntu 18.04

Steps to reproduce

1. Launch Fx
2. Make sure print.tab_modal.enabled is set on true
3. Open any page and hit Ctrl + P
4. Choose as the destination the actual printer
5. Expand More settings
6. Extend the Paper size dropdown and observe the options name

Expected result

• The paper size naming have no additional text added

Actual result

• Every option has a “(Borderless)” ending after the name

Regression range

• Not a regression, this is the content displayed after bug 1662538 landed

Additional notes

• Chrome has no additional naming

Suggested severity

• S4

@jfkthame any idea if there's a way to handle this? It looks like this example printer only has the (Borderless) version. On my WSL Ubuntu connected to a Brother printer I see duplicates of most paper sizes, so Letter and Letter (Borderless).

If that's how a printer chooses to expose its media names, I'm not sure what we can do about it. I suppose if all the paper sizes are named like that, we could arbitrarily decide to trim the (Borderless) suffix from them all for nicer presentation, though it's a horrible hack (and doesn't address the issue of the names all potentially being localized to some other language).

When both Letter and Letter (Borderless) are present as distinct entries in the list, do they actually have different margin data? Presumably you can tell in the preview if you set the margins to "minimum" and then switch between the regular and borderless versions of the paper.

Emily, do you know if there are ways we can be smarter about enumerating the paper sizes? E.g. suppose we specifically count Borderless papers, and compare that to the total number available; if they're the same, then every paper is "borderless" and we might as well strip the suffix if we can recognize it. It all feels very ugly, though....

Do we know if the (Borderless) versions have different hard margins? Can we test that just by trying to set the margins manually in the print preview?

I should've double-checked this before I posted, but it looks like on my WSL Ubuntu it only has (Borderless) on what appear to be "photo" paper sizes. 3.5x5", 5x8", etc. So not as odd as Anca's results and maybe even makes some amount of sense. I do however see two US Letter options, one is borderless (no Minimum margins option) but they're both shown as US Letter.

Changing between the two, 3.5x5" supports Default, Minimum, None and Custom for margins, whereas the 3.5x5" (Borderless) version doesn't support the Minimum option. We had that option when the unwritable margins are 0 so it appears as though they do expose different margin data.

This is a little surprising that you get both since on CUPS systems we are now supposed to be using the PWG names for paper sizes which match known sizes, ignoring any information other than paper dimensions. I would have expected the "letter" entries to have had the same name because of that and the test for unique paper sizes to have removed the duplicate.

It does make sense they both show up as US Letter because of that, though.

That makes me think they are different in actual dimensions too.

I added some logging when switching the paper type and I see this for the US Letter ones:

console.log: ({id:"na_letter_8.5x11in", name:"US Letter", width:612, height:792, unwriteableMarginTop:0.12519685039370076, unwriteableMarginRight:0.12519685039370076, unwriteableMarginBottom:0.12519685039370076, unwriteableMarginLeft:0.12519685039370076})
console.log: ({id:"na_letter_8.5x11in_borderless", name:"US Letter", width:612, height:792, unwriteableMarginTop:0, unwriteableMarginRight:0, unwriteableMarginBottom:0, unwriteableMarginLeft:0})

So I'm not entirely sure this is really a bug per se. These are sizes the print server/driver is telling us have to be addressed differently. They aren't really duplicates, they do have different properties (if only just).

Unless we want to do something like intentionally ignoring any "borderless" sizes? Or possibly only using borderless sizes since they have a larger writeable area? There may be some downside to doing that, like perhaps it is slower to print or might not support duplex on some printers? We could also just coalesce them together into one size (US Letter here), use the smaller hard margins (0.0 from the borderless version), and then choose the one with smaller margins if the user specifies margins smaller than the one with borders can support.

Does the old UI also show these separately? It might be useful to look at what GTK's print code does for cases like this if not.

(Moving bugs to 86, part 1.)

Moving things to 88, cause we're mostly on Proton these days…

I don't see the (Borderless) part in Firefox. I agree this doesn't really seem like a bug. Seems like these are just the names the printer driver is giving us. The related bug 1751610 may help get some of these on to our localized size names.

Emily, feel free to reopen if you think we have a fix here, but I'm not seeing one currently.