Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081005 Minefield/3.1b1pre (.NET CLR 3.5.30729) ID:20081005033754 The background of the the bottom-right corner of the Ctrl-Tab panel isn't hidden. So it shines through the border. Do we have forgotten to set the -moz-border-radius? See the attachment for a detailed view.

I believe this is related to work I'm doing in bug 376408.

I believe the problem here is that this window needs to be something other than a popup class. I tried to address this using window regions in bug 376408, but setting a region blew away the vista glass effect.

taking some notes here - properies for alt-tab TaskSwitcherOverlayWnd: ws_overlapped ws_popup ws_clipsiblings ws_ex_topmost ws_ex_toolwindow ws_ex_layered properties for our ctrl-tab window: ws_overlapped ws_popup ws_clipsiblings ws_clipchildren ws_thickframe ws_ex_toolwindow ws_ex_windowedge

but why is this white background gone when you resize the window?

My patch in bug 506124 still shows this issue. I have a standalone app that has WS_VISIBLE | WS_CLIPCHILDREN | WS_CLIPSIBLINGS and WS_EX_TOPMOST | WS_EX_TOOLWINDOW and doesn't show this issue so I suspect we are doing something wrong. This issue (and most if not all of the aero glass issues) will not show up in VMWare - they require graphics hardware acceleration.

This appears to be caused by the CS_DROPSHADOW class style on the window class.

This patch will create a new native HWND of the same size and parent. It then reparents all the children to the new HWND and stores it back in the nsWindow.

Comment on attachment 390406 [details] [diff] [review] v1.0 +namespace { +static BOOL CALLBACK ReparentWindow(HWND hChild, LPARAM lParam) { + HWND parent = (HWND)lParam; + ::SetParent(hChild, parent); + return TRUE; +} +} The anonymous namespace is superfluous, right? This otherwise looks good, although it's a super hack. Can you separate out the "recreate window" code into a helper function, though?

We're no longer using this ctrl+tab panel in Firefox 4. Is this still a useful report?

(In reply to comment #9) > We're no longer using this ctrl+tab panel in Firefox 4. Is this still a useful > report? It isn't a feature which is enabled by default. You will have to enable it with a pref change in about:config. It's still valid. Rob, what has to be done to get this bug fixed? Doesn't look to be that much, except that the patch could be bitrotted now and that the issue has been fixed on another bug meanwhile?

Now that tab animations rely on this, it is higher priority. What still needs to be done to get this fixed?

I haven't started on this yet and I have a couple weeks of silent software update and related work ahead of me so if anyone wants to grab this in the meantime please feel free.

Hi, my name is Bahno Mirzad and I am currently studying Open-Source Development at Coventry University. For my first bug, I would like to be assigned to this task. Thank you.

NI for comment 16

(In reply to Bahno Mirzad from comment #16) > Hi, my name is Bahno Mirzad and I am currently studying Open-Source > Development at Coventry University. For my first bug, I would like to be > assigned to this task. You're welcome to start work on this bug immediately! The bug will be assigned to you once you've written a patch and attached it or it's otherwise clear that progress is being made. Thanks for wanting to help out!

Visual appearance of Ctrl+Tab panel is now OK, but I thought that this was bug about "any panel". Bug 672710 asked specifically for fixing panels, not "Ctrl+Tab panel". I can still reproduce the bug: 1. Open in non-e10s window attachment 356500 [details] 2. Open inspector, remove red background and blue border from <box> 3. Replace "onload" with "onclick" in markup 4. Click on the page to show panel Either this bug or bug 672710 should be Reopened/Wontfix'd

Hi, I would like to work on this bug as my first bug. I'm very new to this so might need help with it.