Closed Bug 872466 Opened 11 years ago Closed 11 years ago

Drop down menus sometimes not rendering since FF18 release

Categories

(Core :: Widget: Win32, defect)

18 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
firefox21 --- affected
firefox22 --- affected
firefox23 --- verified
firefox24 --- verified
firefox-esr17 --- unaffected

People

(Reporter: bozidar7, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [fixed by bug 844255])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0
Build ID: 20130511120803

Steps to reproduce:

After updating from Firefox 17 to 18 and all following versions, drop-down or pop-up menus (e.g. NoScript) sometimes don't render properly (invisible, only the shadows can be seen).


Actual results:

Initially in version 18, the problem seemed to be limited only to NoScript (and likely other addons). Since 19, it spread to the address bar drop-down and sometimes sub-menus (restore closed tabs, etc.). To my knowledge it only seems to occur on Windows 7 x64, and the problem is resolved if the Aero theme is turned off. Hardware mode doesn't make any difference. Windows is up-to-date, so are the graphics drivers. Running a GeForce 9600 GT, a friend running a GF 460 card never had this problem. On fresh system installs, without any addons, the problem still occurs. Reported that the problem doesn't occur in FF17 ESR. Two topics about it here: http://forums.informaction.com/viewtopic.php?f=7&t=11889 and here http://forums.mozillazine.org/viewtopic.php?f=38&t=2665649 . More info can be found within aswell.


Expected results:

The menus should render properly without any problems
Component: Untriaged → Menus
If you are able to reproduce the issue each time, use mozregression range to find a possible regression range, see http://harthur.github.io/mozregression/
FF18 nightlies started in Aug. 2012 (--good=2012-08-01).

The best thing is to create a new profile and just install NoScript, then run mozreg with this profile.

Of course, be sure your GPU drivers are up-to-date. And it would be good if someone could confirm the possible regression range.
Flags: needinfo?(bozidar7)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0

I'm experiencing this problem as well. I have an AMD Radeon HD 7850 and using Catalyst 13.4 drivers.
In my case, hardware acceleration *does* seem to make a difference, as I haven't had this problem with hardware acceleration turned on. (Although hardware acceleration itself leads to other problems on my system: Bug 837489 and additionally, FF crashes a few seconds after loading www.bahn.de).

With hardware acceleration turned off, the invisible menus manifest themselves. For me, it happens most prominently with RSS bookmarks, but search and address bar drop down menus and occasionally even the Tools menu itself are affected as well.

I've used mozregression on a new profile without any add-ons, the only changes being turning hardware acceleration off, and creating the RSS bookmarks necessary for testing.
In each version, I've repeatedly opened and closed one of the RSS bookmarks too see whether it is affected, and now it looks like 2012-10-07 is the last "good" build, and 2012-10-08 the first "bad" one.
Flags: needinfo?(bozidar7)
JanH, did you try to use mozregression with your new profile and HWA enbabled?
If yes, same regression range?
Flags: needinfo?(jan_thorsten)
I did another mozregression run with HWA on, but I couldn't reproduce the bug that way - that is at least when using the quick method of checking with the help of the RSS bookmarks, everything works fine. I'll try and leave HWA turned on on my main profile for a few days, and see whether I notice anything suspicious during normal usage.
Flags: needinfo?(jan_thorsten)
Small update from me: doesn't seem to be happening with HWA on anymore. It might've been my mistake thinking it does, when I checked last time Firefox was acting weird and I ended up having to make a new profile. So far narrowing it down to occuring on W7 x64 with Aero on and HWA off on Firefox itself. Unfortunately can't do a mozregression still
bozidar7, when you'll have some time, could you run the tool mozreg to confirm the regression range posted in comment #2. It would help, ty.

Anyway, HWA is clearly involved, I think.
2d39dbbe75b3	James H — Bug 610713 - Fix popup menus leaving behind artifacts when using hardware acceleration and a basic Windows theme. r=jmathies
Blocks: 610713
Status: UNCONFIRMED → NEW
Component: Menus → Widget: Win32
Ever confirmed: true
Product: Firefox → Core
Version: 21 Branch → 18 Branch
Reproduced on latest Nightly24.0a1
http://hg.mozilla.org/mozilla-central/rev/4ac6c72b06c8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130521 Firefox/24.0 ID:20130521031106

Steps to Reproduce:
1. Enable Windows7 Aero
2. Trun on all items in performance visual effects
3. Start Firefox without HWA
4. Click chevron in Bookmarks toolbar
5. Repeat Step4 rapidly

Actual Results:
The menupopup become transparent. And there is left a drop shadow.
It looks as if the popup widget is still present, because mouse hover/ click reacts as expected

Try build of Bug 823028 Comment#17 fixes the problem
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jh.dev0@gmail.com-7ef75d6483da
:James
Please consider landing the patch of the try server.
Flags: needinfo?(jh.dev0)
That patch is currently waiting for feedback in Bug 844255 but hasn't seen activity in awhile. Both that and Bug 823028 are related to this and possibly duplicates. I'll see about switching my feedback request to a review request to try to get it landed sooner.
Flags: needinfo?(jh.dev0)
Depends on: 844255
I can reproduce the problem with STR Comment 8 in Firefox22.0 and Beta23.0b1.

However, 
I cannot reproduce in Nightly25.0a1 and Aurora24.0a2 anymore.
This was also fixed by landing of Bug 844255.

http://hg.mozilla.org/mozilla-central/rev/cc80aa0c7c13
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130626 Firefox/25.0 ID:20130626031100
http://hg.mozilla.org/releases/mozilla-aurora/rev/17666746e8cc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130626 Firefox/24.0 ID:20130626004017
Confirmed fix - the status should be changed to "FIXED".
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 844255]
I cannot reproduce the problem with STR Comment 8 in Firefox23b7, Aurora24.0a2 and Nightli25.0a1 as well.

http://hg.mozilla.org/releases/mozilla-beta/rev/1897bd316ab6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 ID:20130718163513
http://hg.mozilla.org/releases/mozilla-aurora/rev/4a29a65a3cba
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130719 Firefox/24.0 ID:20130719004004
http://hg.mozilla.org/mozilla-central/rev/af4e3ce8c487
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130719 Firefox/25.0 ID:20130719030204
Keywords: verifyme
I couldn't reproduce the issue on Fx 20 and 22:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 20130326150557
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
20130618035212
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0

Verified as fixed on Firefox 23 beta 9 (buildID: 20130725195523) and latest Nightly (buildID: 20130725171558).
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0

Verified as fixed on Firefox 24 beta 2 (buildID: 20130812173056) and latest Nightly (buildID: 20130811030225).
Status: RESOLVED → VERIFIED
Keywords: verifyme
This issue seems to have returned since Firefox 28. Can someone confirm?
You're probably seeing bug 986347. It's now fixed in nightly, aurora, and beta. You could switch to beta for now to get the fix.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: