1306974 - drop-down lists for auto-completion sometimes appear black [regression]

Status: RESOLVED INVALID

(Core :: Graphics, defect, P3)

Description

[Clemens Eisserer]

Attachment: black_dropdown.jpg

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160929120120

Steps to reproduce:

The drop-down lists shown by firefox' auto-completion when typing in text fields sometimes appear black.  When typing further the list is rendered as expected.
Happens once in about 15min browsing time.

To be it seems like a regression, I haven't seen this behaviour with pre-50-beta builds, despite using opengl layers and e10s for some time now.

Comment 1

[Clemens Eisserer]

Attachment: contents of about:support

Comment 2

[Clemens Eisserer]

correction, the issue seems to show up more frequently, please find a screencast here: 

https://youtu.be/DzXmeIdFxGc

Comment 3

[Liviu Cirdei]

User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID 	20161004030204

I could not reproduce the issue on Beta 50.0b4 and Nightly 52.0a1. Is the issue reproducible with a new profile[1] and/or in Firefox Safe Mode [2].

Could you try to find a regression range for this using mozregression [3]?

*[1] https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
*[2] https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode 
*[3] http://mozilla.github.io/mozregression/

Comment 4

[Clemens Eisserer]

Attachment: black_url_auto_completion.png

url auto completion popup 52a1

Comment 5

[Clemens Eisserer]

I also experience this issue with the latest nightly 52a1.
Unfortunately, I don't have the environment to bisect it.

Comment 6

[Clemens Eisserer]

maybe there is some correlation with bug 1306971 - it started to show up at about the same time in beta builds.

Comment 7

[Botond Ballo [:botond]]

This sounds very similar to bug 1280653, which was fixed in Firefox 51.

Comment 8

[Marco Castelluccio [:marco]]

(In reply to Clemens Eisserer from comment #5)
> I also experience this issue with the latest nightly 52a1.
> Unfortunately, I don't have the environment to bisect it.

You could use mozregression: http://mozilla.github.io/mozregression/.

Comment 9

[Clemens Eisserer]

botond: bug 1280653 is about correct re-painting of the background invalidated by a popup - however the issue reported here causes the popup itself to be black. Furthermore and as mentioned before, the issue is still reproduceable with Nighly 52.

Comment 10

[Botond Ballo [:botond]]

(In reply to Clemens Eisserer from comment #9)
> botond: bug 1280653 is about correct re-painting of the background
> invalidated by a popup 

I'm not sure what makes you say that. The issue I filed bug 1280653 about involved the popup itself being black.

> Furthermore and as mentioned before, the issue is still reproduceable with Nighly 52.

So, prior to the fix in bug 1280653, the black rendering would only go away after further keystrokes or other user action. With the fix in bug 1280653 in place, I still sometimes see black rendering for a fraction of a second, but it goes away without any user action. In other words, there's still a bug but it's much less severe.

Is it this less severe issue that you're seeing in Nightly?

Comment 11

[Clemens Eisserer]

nope, stays black - attachment 8801818 [details] is a screenshot of 52a1 nightly

Comment 12

[Clemens Eisserer]

however, I use a non-compositing window manager (xfwm4 with compositor turned off) - so maybe thats the difference?

Comment 13

[Botond Ballo [:botond]]

(In reply to Clemens Eisserer from comment #11)
> nope, stays black - attachment 8801818 [details] is a screenshot of 52a1
> nightly

Ok, thanks - looks like it's a different issue than bug 1280653, then.

(In reply to Clemens Eisserer from comment #12)
> however, I use a non-compositing window manager (xfwm4 with compositor
> turned off) - so maybe thats the difference?

It could be. cc'ing Andrew and Karl.

Comment 14

[Clemens Eisserer]

At frist I was almost mislead to think this issue is a driver related bug - because I wasn't able to reproduce the issue on an AMD APU system and also with the software-only llvmpipe driver it didn't show up.

However, when I navigated to the freedesktop bugzilla instance, there it was again - this time firefox was running on top of llvmpipe: https://youtu.be/AiUbagx8OSw

Comment 15

[Clemens Eisserer]

additional info: with llvmpipe I was only able to reproduce the black bars with nightly 52.0a1 (2016-10-17) - the 50b8 beta did not show the issue

Comment 17

[Thomas Daede [:TD-Linux]]

From the intersection with bug 1309378, which has this bug occuring on Intel DRI3 in Gnome 3, it seems that using a compositor does not have an effect, however GL Layers must be on.

Also note that I have screenshots where only part of the popup is black (usually for the search box).

Comment 18

[Clemens Eisserer]

Forgot to mention, I also experience this issue on an Intel system with GL layers enabled:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Haswell Mobile  (0xa16)
    Version: 12.0.3
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Milan, is this something we might aim to fix in 53 or even 52? It has at least duplicate bug reported in the last month.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

This is nightly only, except for people that force GL acceleration.  Granted, there has been a regression in that unsupported scenario, but we don't have the bandwidth to deal with it.

Comment 21

[Clemens Eisserer]

> Granted, there has been a regression in that unsupported scenario, 
> but we don't have the bandwidth to deal with it.

Interesting, especially when considering the goal is to switch to GL accelerated layers by default.

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

After bug 1323284, acceleration is off by default in nightly as well.

Comment 23

[Thomas Daede [:TD-Linux]]

FWIW I've been unable to reproduce this recently (with acceleration forced on) so presumably either something in Nightly, or a driver update fixed it.