Closed Bug 1301920 Opened 6 years ago Closed 6 years ago
[non-e10s] Rendering glitch in <select> drop down menu in Bugzilla Component
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
Attachment #8790055 - Attachment description: <select> drop down menu glitch → <select> drop down menu glitch (4 cases)
Whiteboard: [gfx-note] → [gfx-noted]
This should've been crashing instead of showing nothing. What happens in developer edition for you?
it works without any issue on 50.0a2 (2016-09-12).
regression range is in comment #0. do I need to check with some different configuration?
(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!
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 , which does a COW. We'd be referring to the old SkBitmap before the COW when we called GetBitmapForSurface before MarkChanged().  http://searchfox.org/mozilla-central/source/gfx/2d/SourceSurfaceSkia.cpp#138
Attachment #8791801 - Flags: review?(lsalzman)
Attachment #8791801 - Flags: review?(lsalzman) → review+
Try looks good - https://treeherder.mozilla.org/#/jobs?repo=try&revision=98894f3b4220
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/fece9aa991e6 Call MarkChanged before getting bitmap for surface in skia. r=lsalzman
Confirmed the fix on 51.0a1 (2016-09-18). Thank you :D
You need to log in before you can comment on or make changes to this bug.