Closed Bug 1548484 Opened 6 months ago Closed 5 months ago

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


(Core :: Web Painting, defect, P3)

Windows 10



Tracking Status
firefox-esr60 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- verified


(Reporter: alice0775, Assigned: lsalzman)




(Keywords: regression)


(1 file)

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
  3. Turn mouse wheel up and down on program code area

Actual Results:
Text disappears until reload page

Expected Results:
Text should not disappear

Regression window:

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

Component: Graphics: Layers → Panning and Zooming
Regressed by: 1214261
Has Regression Range: --- → yes
Has STR: --- → yes

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

Blocks: apz-desktop
Component: Panning and Zooming → Web Painting

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.

Flags: needinfo?(lsalzman)
Priority: -- → P3

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()?

Flags: needinfo?(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?

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

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.


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.

Duplicate of this bug: 1546294
Pushed by
respect Cairo blit size limits when using BasicCompositor. r=mattwoodrow
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee: nobody → lsalzman
Flags: qe-verify+

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.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.