Blizzard just noticed this, and I see the same on my Win7 box. Clicking the larry button or bookmark star shows a visual state change, but the associated <panel> is never displayed. (EG, the button looks depressed, and the star is filled in). Tested on current trunk nightly.

The problem goes away now the backout for bug 555133 occurred.

rob, possible that 555133 caused this?

(In reply to comment #2) > rob, possible that 555133 caused this? Yeah, it's possible.

Confirmed. Tested with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100412 Minefield/3.7a5pre

This is back with bug 555133 relanding last night with D2D/DW turned on.

I noticed that the panel is definitely there when you click on Larry or the Star and transparent. I noticed this by having something clickable like a bookmark bar with links on it, etc below where the panel would normally popup and those links are not clickable. However, right click context menus don't suffer from this issue when clicking on the exact same x,y coordinates. Those menus appear.

Here is an example of the transparent panel, and the menu buttons are still functional. This shows how I had clicked in the correct place (x,y) to open the folder selection menu inside the star panel.

This is indeed a direct consequence of bug 555133. If I return opaque for the broken widgets they work fine. For some reason they're considered transparent and then are incorrectly displayed.

So the problem here is that the transparency mode for the panels is set to eTransparencyTransparent since the theme inference patch. Just like for example the middle-mouse button click scrolling image. eTransparencyTransparent is not working with Direct2D. Since it uses WS_EX_LAYERED windows this will require some additional work to fix. There should be two things that need to be looked into: 1. Why is the panel considered a transparent window? It probably shouldn't be, WS_EX_LAYERED has some performance implications to we might want to know. 2. Make Direct2D play nice with completely transparent windows. I will do two so we can get this bug out of the way. But 1 should probably be done as well.

Nice that this is fixed. Certainly would have blocked.

Verified fixed with Firefox 4.0b12pre 20110218.