Can you be specific about the route you are trying to print? Or give a sample starting point that can illustrate the problem. e.g. "90210 to 90005"

dgray@ : Could you please review the screen cast of Win 10 using 52.0.2743.116 and confirm if the blank space in the first page is the issue.

Deleted: 641983_Aug_30.mp4 1.0 MB

	641983_Aug_30.mp4 1.0 MB View Download

The video in comment 3 repros for me. This is the link I used:

https://www.google.com/maps/dir/Union+Station,+800+North+Alameda+Street,+Los+Angeles,+CA+90012/California/@35.4157022,-119.9240142,8z/am=t/data=!3m1!4b1!4m13!4m12!1m5!1m1!1s0x80c2c64160adbc4b:0x527217f541ae2569!2m2!1d-118.2365021!2d34.056219!1m5!1m1!1s0x808fb9fe5f285e3d:0x8b5109a227086f55!2m2!1d-119.4179324!2d36.778261

I bisected this to https://chromium.googlesource.com/chromium/src/+log/fd3dd99c434e9e4ea371899c88 so my guess is r337670 -> https://chromium.googlesource.com/chromium/blink/+log/b42dbb0..3a26716 -> https://chromium.googlesource.com/chromium/blink/+/3a26716b1b4fffe8a3e180c36111f9db207476e0 ?

mstensho: Can you help take a look to determine if there's anything we can do on the Chromium/Blink side, or if I should ask Google Maps to change their HTML/CSS.

Yes, this was caused by the LayoutBlockFlow::adjustForUnsplittableChild() change in that CL.

I can only reproduce it when printing in Landscape, BTW. In portrait mode the page is tall enough for both the notes and the map to fit on one page.

Sorry, I followed the steps to reproduce the problem, and didn't watch the video. So I thought it was all about the map being pushed to the next page. But without the map, I can reproduce this in portrait mode too. The directions are pushed to the next page, even though a lot of them could fit on the first page.

In any case, it's about that code line change in LayoutBlockFlow::adjustForUnsplittableChild().

I noticed that the directions section is inside some block with overflow-y:auto. This effectively disables pagination for that block and makes it unsplittable.

As far as I can tell, this page is generated for the very purpose of printing, so why use overflow:auto? Nobody wants scrollbars on paper, anyway. :) Maybe this is something for the Google Maps team to look into?

That said, it seems that no other engine than Blink (and WebKit?) treats overflow-y:auto as unsplittable when printing. They only do that for multicol.

The spec https://drafts.csswg.org/css-break/#possible-breaks currently says:

"Some content is not fragmentable, for example many types of replaced elements [CSS21] (such as images or video), scrollable elements, or a single line of text content. Such content is considered monolithic: it contains no possible break points. Any forced breaks within such boxes therefore cannot split the box, and must therefore also be ignored by the box’s own fragmentation context.

In addition to any content which is not generally fragmentable, UAs may consider as monolithic any elements with overflow set to auto or scroll and any elements with overflow: hidden and a non-auto logical height (and no specified maximum logical height)."

So we're not violating the spec. But the spec says that we MAY treat such elements as monolithic. We don't HAVE TO. And the other engines don't. For printing. But they do for multicol. I guess slicing an interactive scrollbar into columns is too weird, and there may also be paint-technical reasons. Printing, on the other hand, is non-interactive and lovely, so allowing fragmentation inside blocks with non-visible overflow there isn't so hard or weird.

So, as I mentioned, there are pagination issues with printing the actual map as well, but that deserves a new bug report (or it should be fixed by the Google Maps team; not sure if the engine is doing anything wrong).

Let's limit this bug to the unwanted page break before the directions / route plan, since that seems to be what the reporter cares about.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/53d4d7aff8e25eae2ece5bbf5a53eec940871fa8

commit 53d4d7aff8e25eae2ece5bbf5a53eec940871fa8
Author: mstensho <mstensho@opera.com>
Date: Wed Aug 31 16:13:38 2016

Fragment blocks with non-visible overflow as normally when printing.

Splitting scrollbars into multiple fragmentainers is only problematic in
interactive media. We don't need to impose any such pagination restrictions
when printing, since printing is non-interactive,

BUG= 641983 

Review-Url: https://codereview.chromium.org/2298193002
Cr-Commit-Position: refs/heads/master@{#415645}

[add] https://crrev.com/53d4d7aff8e25eae2ece5bbf5a53eec940871fa8/third_party/WebKit/LayoutTests/printing/overflow-auto-expected.html
[add] https://crrev.com/53d4d7aff8e25eae2ece5bbf5a53eec940871fa8/third_party/WebKit/LayoutTests/printing/overflow-auto.html
[modify] https://crrev.com/53d4d7aff8e25eae2ece5bbf5a53eec940871fa8/third_party/WebKit/Source/core/layout/LayoutBox.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0928918d8e570a7367a571d158a34933077e7022

commit 0928918d8e570a7367a571d158a34933077e7022
Author: paulmeyer <paulmeyer@chromium.org>
Date: Wed Aug 31 19:10:58 2016

Revert of Fragment blocks with non-visible overflow as normally when printing. (patchset #1 id:1 of https://codereview.chromium.org/2298193002/ )

Reason for revert:
Suspected cause of "virtual/threaded/fast/scroll-behavior/smooth-scroll/main-thread-scrolling-reason-correctness.html" failures in webkit_tests on "WebKit Linux (dbg)" bot.

example: https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20%28dbg%29/builds/9099

Original issue's description:
> Fragment blocks with non-visible overflow as normally when printing.
>
> Splitting scrollbars into multiple fragmentainers is only problematic in
> interactive media. We don't need to impose any such pagination restrictions
> when printing, since printing is non-interactive,
>
> BUG= 641983 
>
> Committed: https://crrev.com/53d4d7aff8e25eae2ece5bbf5a53eec940871fa8
> Cr-Commit-Position: refs/heads/master@{#415645}

TBR=eae@chromium.org,mstensho@opera.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 641983 

Review-Url: https://codereview.chromium.org/2300763002
Cr-Commit-Position: refs/heads/master@{#415712}

[delete] https://crrev.com/01cdf399a2720f0ac49cd3512c0cdfc8b0439f68/third_party/WebKit/LayoutTests/printing/overflow-auto-expected.html
[delete] https://crrev.com/01cdf399a2720f0ac49cd3512c0cdfc8b0439f68/third_party/WebKit/LayoutTests/printing/overflow-auto.html
[modify] https://crrev.com/0928918d8e570a7367a571d158a34933077e7022/third_party/WebKit/Source/core/layout/LayoutBox.cpp

I'll try to reland this soon. Let's keep the bug open in the meantime.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/054e1dec56f7a7a76f64adc9b3a27c94d0778e33

commit 054e1dec56f7a7a76f64adc9b3a27c94d0778e33
Author: paulmeyer <paulmeyer@chromium.org>
Date: Thu Sep 01 21:23:35 2016

Reland of Fragment blocks with non-visible overflow as normally when printing. (patchset #1 id:1 of https://codereview.chromium.org/2300763002/ )

Reason for revert:
The reverted CL seems not to have been the problem.

Original issue's description:
> Revert of Fragment blocks with non-visible overflow as normally when printing. (patchset #1 id:1 of https://codereview.chromium.org/2298193002/ )
>
> Reason for revert:
> Suspected cause of "virtual/threaded/fast/scroll-behavior/smooth-scroll/main-thread-scrolling-reason-correctness.html" failures in webkit_tests on "WebKit Linux (dbg)" bot.
>
> example: https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20%28dbg%29/builds/9099
>
> Original issue's description:
> > Fragment blocks with non-visible overflow as normally when printing.
> >
> > Splitting scrollbars into multiple fragmentainers is only problematic in
> > interactive media. We don't need to impose any such pagination restrictions
> > when printing, since printing is non-interactive,
> >
> > BUG= 641983 
> >
> > Committed: https://crrev.com/53d4d7aff8e25eae2ece5bbf5a53eec940871fa8
> > Cr-Commit-Position: refs/heads/master@{#415645}
>
> TBR=eae@chromium.org,mstensho@opera.com
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 641983 
>
> Committed: https://crrev.com/0928918d8e570a7367a571d158a34933077e7022
> Cr-Commit-Position: refs/heads/master@{#415712}

TBR=eae@chromium.org,mstensho@opera.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 641983 

Review-Url: https://codereview.chromium.org/2294883007
Cr-Commit-Position: refs/heads/master@{#416058}

[add] https://crrev.com/054e1dec56f7a7a76f64adc9b3a27c94d0778e33/third_party/WebKit/LayoutTests/printing/overflow-auto-expected.html
[add] https://crrev.com/054e1dec56f7a7a76f64adc9b3a27c94d0778e33/third_party/WebKit/LayoutTests/printing/overflow-auto.html
[modify] https://crrev.com/054e1dec56f7a7a76f64adc9b3a27c94d0778e33/third_party/WebKit/Source/core/layout/LayoutBox.cpp