The relevant code is in chrome/browser/printing/print_preview_dialog_controller.cc in PrintPreviewDialogDelegate::GetDialogSize().

CC kuscher as an FYI b/c we had talked about this previously

CC bartfab and poromov as this might be relevant for some of their work with Android on Chrome OS

BTW, this is not the same as Mac. On Mac, we are limiting the maximum size, but here we are trying to limit the minimum size.

I believe on Mac, we limit both max and min size. In the "Other Considerations" section of the 1Pager, I noted that the behavior we care most about on CrOS is limiting minimum size. If it's easiest to limit both, that should be more than fine as well. I'm not sure why neither was limited on CrOS to begin with. Thanks again for the help Lei!!

We do have a minimum size on Mac, but I suspect it might use some mac-specific magic that we don't have on other platforms with Views. Maybe wittman@ knows how all of this works and can comment on the feasibility here?

+tapted as well.

The print preview window is implemented using a constrained window within Views, which limits the window to the extent of the parent browser window.

As far as I know there is no concept in Chrome Views of a window that is both anchored to the browser window and extends outside of it. Supporting this would require a substantially different implementation and very likely a large amount of work.

Understood. Hopefully this will be do-able for Android apps on Chrome OS, as I believe the windowing system will be independent, but I'm not certain. poromov@ will likely tackle that for M54. This is a much higher priority ask for the Android app scenario.

For Chrome on Chrome OS, given the amount of work required to spin this up, let's put this on the back burner until we see greater demand. Marking this as available w/ a lower priority.

Thanks for the help thestig@ and wittman@! 

Can initialize the constrained window with a minimum size. This prevents the displayed print preview from shrinking with the window past the minimum size, but instead of overflowing out of the window it is cut off at the window boundaries, and only the top left corner is visible. 

> no concept in Chrome Views of a window that is both anchored to the browser window and extends outside of it. Supporting this would require a substantially different implementation and very likely a large amount of work.

This is most of the way there already. E.g. the App Info dialog is such a dialog (chrome://extensions, click 'Details'). It is currently window-modal, but it can be made tab-modal like print preview just by changing a setting (which we already do if this dialog is shown on Mac -- see https://cs.chromium.org/chromium/src/chrome/browser/ui/views/apps/app_info_dialog/app_info_dialog_container.cc?sq=package:chromium&l=38). On ChromeOS, this dialog extends outside the parent.

Where it gets weird is (I think) on Linux. On Linux, dialogs tend not to be "toplevel", and so they get clipped to their parent window bounds. I think Windows 7 with the "classic theme" (or over RDP) also does this, but Win8 dropped support for the classic theme. It's probably not hard just to force the print preview dialog to be toplevel. Probably only Linux will encounter a bit of jank since creating new toplevel windows has a bit more latency there.

Maybe we can just make the Print Preview dialog window-modal (or even app-modal?) We have corner case problems with window.print() in one tab causing another tab that shares the renderer to not do JS correctly, so more modal-ness will help prevent that problem, at the cost of not letting users do simultaneous print previews.

When I was working on the constrained windows (on Windows) I made an initial attempt at making them top-level and recall it being fairly painful, with a number of event handling subtleties. But this was a while ago and pre-Aura, so it's entirely possible the situation has changed since then.

Moving to a window modal approach, we will lose the ability to print from different tabs in the same window correct?, but we will not lose the ability to print from different windows at the same time correct?

I suspect that frequency of printing from multiple tabs in the same window is lower priority than trying to print when the window itself is small, thus the tradeoff would be worthwhile. I suspect that opening the print dialog and initiating a print job is a fairly atomic sequence of actions. Furthermore, having multiple windows open side by side will almost always leave one window small enough such that a print dialog in that state is troublingly small.

We do not currently have great data on what the typical window size is when printing or the number of print dialogs opened concurrently. If there is debate on this topic in terms of the tradeoffs, implementing those in UMA would be a reasonable step forward, but I suspect we should be good to move forward otherwise.

Window modal would allow print previews from different windows (but not different tabs). However, the current approach is to extend the dialog outside the window on ChromeOS while remaining child modal, rather than converting print preview to window modal. This will allow print previews from multiple tabs as occurs now. The modification will be for ChromeOS only as other platforms cut off the child window at the parent window boundaries.  

Oh that's perfect :) The best of both worlds! Thanks Rebekah. Also, noticed that you just joined. Welcome to the team!

 Issue 224577  has been merged into this issue.

Just wondering if there is any update on this issue? Thanks!