From testing trying to turn on SW-WR popups, we often hit an assert where the stride is too small for the buffer size:

[task 2021-03-09T19:09:19.459Z] 19:09:19     INFO - GECKO(3132) | [AO] StartCompositing -- widget 94x189; beginFrame 654x189; startCompositing 654x189, allocateMappedBuffer 654x189
[task 2021-03-09T19:09:19.459Z] 19:09:19     INFO - GECKO(3132) | [AO] AllocateMappedBuffer -- widget 94x189; beginFrame 654x189; startCompositing 94x189, allocateMappedBuffer 654x189
[task 2021-03-09T19:09:19.460Z] 19:09:19     INFO - GECKO(3132) | [AO] AllocateMappedBuffer -- from LockBits; size 94x189, bounds (0,0) 654x189, widget size 94x189 (was 94x189)
[task 2021-03-09T19:09:19.460Z] 19:09:19     INFO - GECKO(3132) | [AO] InitDefaultFramebuffer: offset (0, 0) -> (0, 0)
[task 2021-03-09T19:09:19.460Z] 19:09:19     INFO - GECKO(3132) | [AO] set_tex_storage: size changed w=0 h=0 f=00008058 -> w=654 h=189 f=00008058
[task 2021-03-09T19:09:19.460Z] 19:09:19     INFO - GECKO(3132) | [AO] width=654 height=189 size=0 bpp=4 stride=2616 format=00008058 old_stride=0 new_stride=376
[task 2021-03-09T19:09:19.460Z] 19:09:19     INFO - GECKO(3132) | Assertion failed: new_stride >= size_t(bpp() * width), file src/gl.cc, line 445

I added prints which show the widget size changes between the BeginFrame call and the StartCompositing/AllocateMappedBuffer call.

Sometimes we end up racing on the widget size, and it can shrink between
BeginFrame and StartCompositing. We calculated our dirty region based on
the previous widget size, so we need to clamp the bounds here to ensure
we remain within the buffer.

https://hg.mozilla.org/mozilla-central/rev/49e05529d25e