"browsingContext.print" with custom scaling should not use default value (true) of "shrinkToFit" argument

[whimboo]

Right now the shrinkToFit argument of the browsingContext.print command defaults to true. That even when a client specified the scale argument with a different value than 1. As result in Firefox the scaling is not applied at all.

When I check the print options of Safari I can see that Scale to fit paper size doesn't have any effect when a scaling value is set. Also Chrome behaves that way when using the system print dialog on MacOS. In it's own UI a Shrink to Fit option is not even visible. And in Firefox Shrink to Fit and Scale are options that are mutual exclusive.

Should we consider not applying shrinkToFit when scale has a custom value?

Note that this will also apply to WebDriver classic, and would require a separate PR.

CC @gsnedders @sadym-chromium, @jgraham

[OrKoN]

by reading the description of shrinkToFit:

Resize the content to match the page width, overriding any page width specified in the content

it sounds like the goal of the parameter is to discard any page sizes coming from the content (CSS on the page). I do not think it should be mutually excluding with the scale. After the page sizes from the content has been discarded, it is still possible to scale. I think shrinkToFit needs more explanations about how to apply it. In Puppeteer, we have a hint called preferCSSPageSize which tells whether the sizes from the content have to be taken into account or if we need to resize according and fit into the provided page dimensions.