It's pretty hard to imagine what's going on without a test case. Could you please attach one? Thanks!

It basically doesn't seem to work... if I have time then I will add a test case... needs a CSS person here who can actually make changes though...

If you have time to create a test case, please reopen this bug at that point. Closing this as unpronounceable until then.

Why can't someone at Google create a test case? I am not likely going to create one in the near future.. so that's it? No more bug fixes at Google unless the submitter does this kind of legwork? I'm re-opening this. If Google abandoned Chromium then feel free to close it again and maybe in a few months I'll do a test case, if I remember!

Thank you for providing more feedback. Adding requester "meade@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

agamemnus@, thanks for your response. Typically we ask for test cases because we can't reproduce the issue locally, and need a test case to make sure we're looking at the right thing.

For example, https://jsfiddle.net/cjn0udyf/1/ reproduces the conditions you described in your report, yet behaves as expected on Canary. Without a test case that is known failing for you, there is nothing else we can do.

I'd also like to invite you to read https://www.chromium.org/conduct and help us ensure that future communication is conducted in line with providing a respectful and constructive community.

I am reciprocating by working a bit more and creating the test case. It seems that the issue is actually just in the .innerHTML part of it (seemingly). Take a look:

https://jsfiddle.net/cjn0udyf/2/

Separately, given that I'm not being paid to post reports or do test cases, and it looked like no well-paid Google employees were given an opportunity to at least create a sample test with my description, it seemed like I was being coerced to write a test case, or have the bug get shut down. Your test case, though, inspired me to finally find the bug with my own test case, so thanks for that.

This behavior is per-spec: https://www.w3.org/TR/css-break-3/#page-break-properties (specifically 

"For compatibility with CSS Level 2, UAs that conform to [CSS21] must alias the page-break-before, page-break-after, and page-break-inside properties to break-before, break-after, and break-inside by treating the page-break-* properties as shorthands for the break-* properties with the following value mappings:

always: page
").

There's no bug here.

Incidentally, this is precisely why we ask for reporters to provide test cases when they can, so that the behavior they're describing is made clear. Both meade@ and I tried to reproduce your issue from the description but couldn't - please assume good intentions from engineers on the project.

Ok, so I think I understand this a bit better now, thanks.