With a crash report like the one above, I don't understand why this is not a Blink issue. Adding Paint since the crash is inside blink::FrameView::prePaint().

SPV2 (--enable-slimming-paint-v2) still has several crashes when devtools is open, but I think this specific crash is the interaction between print browsing and paint invalidation. I think this line may be the issue:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintInvalidator.cpp?l=427

Doesn't seem like CSS?

The line pointed out by pdr@ shouldn't execute if printBrowser is enabled though...

pdr@ is implying that we would normally return when printing, but with printBrowser we keep on going and crash. I interpret that to mean that something is unsafe when in printing paint mode, but we need that unsafe thing for printBrowser, so we crash.

I can't reproduce this on ToT. I guess the original bug was because for DevTools page, paint invalidation is in non-printing mode and painting is in printing mode, causing mismatch of GraphicsLayers.

Currently we don't invalidate paint for normal printing paint mode because
- We flatten GraphicsLayers when printing, while paint invalidation invalidates on GraphicsLayers.
- For printing we always paint on a special canvas instead of GraphicsLayers, and paint invalidation doesn't apply.
- There is no update of web page during printing, so no paint invalidation is needed.
- Printing paint doesn't happen during document lifecycle update.

However, there are a lot of differences in PrintBrowser mode and it seems that we do need to invalidate paint.

I have some questions:
- Should we create composited layers in PrintBrowser mode?
- If we create composited layers, should we flatten the layers during painting?
- If we create composited layers and flatten layers during painting, how should we invalidate paint?
- Should we show DevTools in printing mode (which looks not good to me)?

I think the answers depend on what PrintBrowser is supposed to provide. Where can I find docs of it?

I found the design doc: https://docs.google.com/document/d/1G2RoH7yiwh_vosEHsHTwqETBvt2ij8p9ov0D3kIz4ww/edit#

After reading the design doc, I try to answer my questions:

1. Should we create composited layers in PrintBrowser mode?
A: Yes. We should modify the rendering pipeline as little as possible.
  
2. If we create composited layers, should we flatten the layers during painting?
A: No. Same reason.

3. If we create composited layers and flatten layers during painting, how should we invalidate paint?
A: Just normal paint invalidation.

4. Should we show DevTools in printing mode (which looks not good to me)?
A: DevTools should be rendered in non-printing mode. This helps developers to debug pages in printing mode.

And a new question:
5. What should we do in real printing in PrintBrowser mode?
A: We should do exactly the same as in non-PrintBrowser mode.

If my answers are agreed, we have the following works to do for PrintBrowser:
2. Painting should not flatten GraphicsLayers for PrintBrowser mode.
4. DevTools should be rendered in non-printing mode.
5. We should distinguish real printing in PrintBrowser mode.

I come to different conclusions. If the primary goal is to debug and test the printing pipeline, we need to do as much as we possibly can to maintain the behavior of that pipeline. What we do with layerization etc is as important part of how printed content is generated. e.g. bugs in how we flatten layers for printing will not manifest if we do not flatten.

Now if the goal is just to check the layout aspects of printing, e.g. how media settings are applied, then how we render it is less important. But that's not how I interpret the document.

Can someone clarify?

I modified the summary because I believe the crash was because of the mismatch between painting and other stages about flattening GraphicsLayers.

After reading schenney@'s comment, I changed my mind about compositing. I thought it was complex not to create compositing layers in blink compositing, but realized we have already achieved this for SPv2. We just need the same mechanism for PrintBrowser.

Note that this is still not the same printing pipeline in which we create composited layers then flatten them during printing, but the difference will disappear in spv2.

I see that now PrintBrowser implies SlimmingPaintV2, so this bug seems to no longer exist. Can we close this?

I intend to implement PrintBrowser on SPV1 too - to make it stable to use. 

Let's keep this open in that case?

Closing this since the objective in #15 has been achieved.