1548484 - Github Text disappears when scroll up/down by mouse wheel if HWA is disabled

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P3)

Description

[Alice0775 White]

This problem is only happen if HWA is disabled and e10s is enabled

Reproducible: always

Steps to reproduce:

1. Make sure HWA is disabled and e10s is enabled
2. Open https://github.com/openSUSE/opensuse-theme-chameleon/blob/master/test/wiki-en-main-page.html
3. Turn mouse wheel up and down on program code area

Actual Results:
Text disappears until reload page

Expected Results:
Text should not disappear

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4b6953e2aa2b936dc97065ea53c8bd6ad2900e17&tochange=9e172c20b8f9571ddcb7926cc722af4e4403dd50

Triggered by:
9e172c20b8f9571ddcb7926cc722af4e4403dd50 David Anderson — Fix crash trying to allocate textures for oversize scrollbars. (bug 1214261, r=mstange)

Comment 2

[Alice0775 White]

Workaround:
setting layers.async-pan-zoom.enabled to false in about:config.

Comment 3

[Matt Woodrow (:mattwoodrow)]

This page is creating a giant mask layer, 978x40040 which gets clamped to the max texture size (as reported by DrawTargetSkia::GetMaxSurfaceSize) to 978x32767.

I haven't yet figured out what happens after that, but we stop being able to mask correctly.

Lee, do you have any ideas on what might cause this? Any other limitations that Skia might be added to stop giant surfaces from working?

A cursory look at SkSurface::MakeRaster suggests that it should be ok.

Reducing the size (within CreateMaskLayer) to 2048 makes things work correctly. Clamping to max size in each dimension may not be great, but it'd be good to understand roughly what our limitations are.

Comment 4

[Lee Salzman [:lsalzman]]

The one limitation I can see is that Skia mask images are limited to be no more than 2^31 bytes in total size, so the product of both dimensions must be less than 2^31. In this case, 978*32767 should still be comfortably below this limit, so I am not sure that would affect us here?

Another possibility is that maybe inside DrawTargetSkia::Mask() or MaskSurface(), whichever happens to be getting called in this case, that we are just silently OOMing in tryAllocPixels() or ExtractAlphaForSurface()?

Comment 5

[Lee Salzman [:lsalzman]]

Hmm, I can't reproduce this on my Windows 7 machine at all. Matt, can you check if it is makes the computeImageSize() check inside SkDraw::drawBitmapAsMask() that is failing, or if we are failing higher up in those DrawTargetSkia calls?

Comment 6

[Matt Woodrow (:mattwoodrow)]

So it looks like we're using DrawTargetCairo, not DrawTargetSkia...

Comment 7

[Matt Woodrow (:mattwoodrow)]

We're using Cairo because of [1] and [2].

We're choosing 32767 because [3] thinks we're going to use Skia, as that's the content backend we chose (but not what the widget gives us). Note that both DrawTargetCairo::GetMaxSurfaceSize() and DrawTargetSkia::GetMaxSurfaceSize() both return 32767, so the mismatch doesn't actually matter in this case.

We fail to draw anything because this [4] code is using >= 32767, not > 32767.

[1] https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/widget/windows/WinCompositorWidget.cpp#105
[2] https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/widget/windows/WinCompositorWidget.cpp#180
[3] https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/gfx/layers/basic/BasicCompositor.cpp#221
[4] https://searchfox.org/mozilla-central/source/gfx/cairo/libpixman/src/pixman.c#435

Comment 8

[Matt Woodrow (:mattwoodrow)]

Dropping DrawTargetCairo's GetMaxSurfaceSize by 1 is a correct thing to do, but won't be sufficient here, as the content process think we're using skia.

Comment 10

[Lee Salzman [:lsalzman]]

Attachment: Bug 1548484 - respect Cairo blit size limits when using BasicCompositor. r?mattwoodrow

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1df96f5e6402
respect Cairo blit size limits when using BasicCompositor. r=mattwoodrow

Comment 12

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/1df96f5e6402

Comment 13

[Alexandru Trif, Desktop QA [:atrif]]

Hello,
Reproduced the issue with Firefox 68.0a1 (20190502220333) on Windows 10 x64 using steps from comment 0.
The issue is verified using Firefox 68.0b7 (20190603181408) on Windows 10x64.