1301920 - [non-e10s] Rendering glitch in <select> drop down menu in Bugzilla Component

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Tooru Fujisawa [:arai]]

Attachment: <select> drop down menu glitch (4 cases)

Steps to reproduce:
  1. open Firefox Nightly (2016-09-10) 64bit on OSX 10.11.6, with clean profile
  2. open about:preferences and turn "Enable multi-process Nightly" of
  3. restart Firefox

  4. open https://bugzilla.mozilla.org/
  5. login with an account that has "can edit any bug" permissions
  6. in Bugzilla's General Preferences, turn "Use experimental user interface" on

  7. open bug 1299738 (or maybe this bug too)
  8. click "Edit" button
  9. open "Component" drop down menu, for "Core Product"
 10. scroll up and down the drop down menu randomly for several seconds

Actual result:
  Rendering glitch happens, like the attached image.

Expected result:
  No glitch.


Regression range:
  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0cfb84806c0863af4facbdde2b37ac5fdd40567c&tochange=657ba2f2611c714d718fb0268acfd5e60ff44310


unchecking "Use hardware acceleration when available" in about:preferences Advanced pane doesn't change the behavior.

changing gfx.content.azure.backends pref to "cg" makes drop down menu (and any popup) invisible.


here's Graphics section of about:support:

Graphics
--------

Features
Compositing: OpenGL
Asynchronous Pan/Zoom: none
WebGL Renderer: NVIDIA Corporation -- NVIDIA GeForce GT 750M OpenGL Engine
WebGL2 Renderer: NVIDIA Corporation -- NVIDIA GeForce GT 750M OpenGL Engine
Hardware H264 Decoding: Yes
Audio Backend: audiounit
GPU #1
Active: Yes
Vendor ID: 0x10de
Device ID: 0x0fe9

Diagnostics
AzureCanvasAccelerated: 1
AzureCanvasBackend: skia
AzureContentBackend: skia
AzureFallbackCanvasBackend: none
TileHeight: 512
TileWidth: 512

Comment 1

[Mason Chang [Inactive] [:mchang]]

This should've been crashing instead of showing nothing. What happens in developer edition for you?

Comment 2

[Tooru Fujisawa [:arai]]

it works without any issue on 50.0a2 (2016-09-12).

Comment 3

[Tooru Fujisawa [:arai]]

regression range is in comment #0.
do I need to check with some different configuration?

Comment 4

[Mason Chang [Inactive] [:mchang]]

(In reply to Tooru Fujisawa [:arai] from comment #3)
> regression range is in comment #0.
> do I need to check with some different configuration?

Oh sorry, forgot about that. Thanks!

Comment 5

[Mason Chang [Inactive] [:mchang]]

Attachment: Call MarkChanged before getting bitmap for surface

This was happening because we'd call GetBitmapForSurface before calling MarkChanged. The surfaces we'd get from aSurface were the same as DrawTargetSkia::mSnapshot, which would eventually call [1], which does a COW. We'd be referring to the old SkBitmap before the COW when we called GetBitmapForSurface before MarkChanged().

[1] http://searchfox.org/mozilla-central/source/gfx/2d/SourceSurfaceSkia.cpp#138

Comment 6

[Mason Chang [Inactive] [:mchang]]

Try looks good - https://treeherder.mozilla.org/#/jobs?repo=try&revision=98894f3b4220

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fece9aa991e6
Call MarkChanged before getting bitmap for surface in skia. r=lsalzman

Comment 8

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/fece9aa991e6

Comment 9

[Tooru Fujisawa [:arai]]

Confirmed the fix on 51.0a1 (2016-09-18).
Thank you :D