1657010 - Tab-modal printing UI isn't wide enough due to long printer names, nor tall enough to preview an entire single sheet of paper

Status: RESOLVED DUPLICATE of bug 1656298

(Toolkit :: Printing, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot

STR:

1. Start Firefox Nightly with a fresh profile.
2. Go to about:config and toggle print.tab_modal.enabled to true.
3. Visit https://example.org
4. Ctrl+P to trigger the print UI.

ACTUAL RESULTS:
See screenshot. There are two nearly-unnecessary scrollbars:
(A) There's a vertical scrollbar for the print preview area, which is barely too short to show the full page.
(B) There's a horizontal scrollbar for the print settings area, which is barely not wide enough to show its content.

EXPECTED RESULTS:
The dialog area should be slightly larger to fit the content.
Or, perhaps the "preview" area should be slightly skinnier so that the page will vertically shrink a little bit so as not to overflow vertically (removing scrollbar "A"), & to give more horizontal space for the settings (removing scrollbar "B")

Comment 1

[Daniel Holbert [:dholbert]]

Note that I'm using the default window-size. (It makes sense that some UI might overflow if I had a tiny browser-window, but it's odd that things overflow even at the default window size.)

It looks like the settings panel is 250px wide. The things that are overflowing in the settings panel are:

• <input id="copies-count" type="number" min="1"> -- this element is 247px wide (which overflows the 250px available, given that it's indented). This is simply the default width of <input type="number"> widgets on Linux. (data:text/html,<input type="number"> renders as 246px wide, not sure where the extra pixel comes from in 246 vs 247 -- maybe font size or something -- but it's inconsequential.)

• <select is="destination-picker" id="printer-picker"> -- for me, this element is 245px wide (which overflows the 250px available, given that it's indented). This element seems to be sized based on the printer names that it contains, which means it can be arbitrarily wide. On my system, there's an option with label CUPS/Brother_MFC_J6535DW which is the longest name in the list & which seems to be propping up that size.

SUGGESTIONS
We should probably do the following:

• Limit the width of the select dropdown element (and probably limit the size of the strings that we'll put in its option elements), perhaps with a max-width like max-width: calc(100% - 18px) (where 18px is to account for the the hardcoded padding on the section frame here)
• Set a smaller width on the "copies" entry -- maybe using the <input size="..."> attribute (e.g. size="3", which should be wide enough for at least 3 digits; it seems reasonable to assume that nobody's going to want to print more than 999 copies, and the edge-casey few who do can perhaps tolerate an overflowing number frame).)

And perhaps also:

• Limit the length of the printer name that we'll show in the <option> dropdown (to prevent that dropdown popup frame being insanely wide for a ridiculously-wide printer name)
• Make the whole dialog more content-sized? (Though this is less of an issue if the unkonwn-sized-content has max-width attributes.)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of suggested improvement after adding my suggested `max-width` property and `size` attribute

Here's a screenshot showing the improvement from making my first two suggestions in comment 1. (which I did locally in devtools)

(Note that we also need to add a size attribute to the scale textfield that's inside of the "More Settings" area. Otherwise, that field causes similar overflow issues as soon as you expand More Settings.)

Comment 3

[:Gijs (he/him)]

(In reply to Daniel Holbert [:dholbert] from comment #1)

Note that I'm using the default window-size. (It makes sense that some UI might overflow if I had a tiny browser-window, but it's odd that things overflow even at the default window size.)

The default window size is based on your display resolution, so I don't think this matters. We just need to make sure things behave gracefully here.

Did you figure out what caused the vertical scrollbar?

Mark, can you set a severity/priority and/or find an assignee? :-)

Comment 4

[:Gijs (he/him)]

Attachment: Printer names are terrible.png

Note that printer names can get a lot worse... Windows likes to make copies of mine. :-(

Comment 5

[Mark Striemer [:mstriemer]]

Bug 1657010 was filed to look at getting these element's sizes match more closely with the mocks.

There's also bug 1654962 to resize the print preview area based on the available screen size. I added a comment there that we should try and fit a full page in the preview if possible.

There could likely be some work done on the platform side to improve the sizing of the preview as well to fit a single page. If there was slightly more padding around the page then it would fit, but then if we make the preview browser wider for wider screens the preview will also get wider and fit less vertical content.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to :Gijs (he/him) from comment #3)

Did you figure out what caused the vertical scrollbar?

I didn't dig there, but I think it's just that:

• The aspect ratio of this dialog's print-preview display area has a slightly wider "width-to-height" ratio than a US Letter.
• We size the previewed paper to fill (but not exceed) the available width, because we're happy to scroll vertically & expect that will be common, but don't really want to make the user scroll horizontally.
• This means the previewed paper ends up being slightly taller than the available height, which creates a vertical scrollbar.

Comment 7

[Daniel Holbert [:dholbert]]

There could likely be some work done on the platform side to improve the sizing of the preview as well to fit a single page.

(This is one way to address the vertical scrollbar issue, and might be the only way to address it in the general case of unforeseen bizarre page sizes that we get back from the printer.)

Comment 8

[:Gijs (he/him)]

(In reply to Daniel Holbert [:dholbert] from comment #6)

(In reply to :Gijs (he/him) from comment #3)

Did you figure out what caused the vertical scrollbar?

I didn't dig there, but I think it's just that:

• The aspect ratio of this dialog's print-preview display area has a slightly wider "width-to-height" ratio than a US Letter.
• We size the previewed paper to fill (but not exceed) the available width, because we're happy to scroll vertically & expect that will be common, but don't really want to make the user scroll horizontally.
• This means the previewed paper ends up being slightly taller than the available height, which creates a vertical scrollbar.

Hm, but this should be even worse for A4 then (as it is narrower and taller)... :-(

Comment 9

[Mark Striemer [:mstriemer]]

It would likely result in a better experience if we fit the height of the preview page to the available height, rather than fitting the width (if possible). Chrome seems to default to that setting (if it's a single page document there won't be a scrollbar) but provides +/- zoom options and a button to switch between fit page and fit to width.

I tried my hand at modifying the width-fitting code to fit the height instead and can't say I made any real progress.

Daniel, do you think fitting the height of the page would be possible, and do you think it's worth it/would help with the scrollbar confusion?

Comment 10

[Daniel Holbert [:dholbert]]

Probably possible & worth it. Filed bug 1658173 on that part.