hard one to explain, but: 1) go to maps.google.com 2) when you move the cursor over the map, it appears as a black box with the hand cursor. it almost looks inverted? I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070606 Minefield/3.0a6pre

I can't reproduce, using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070607 Minefield/3.0a6pre.

Thanks for checking, Gavin. FWIW, I see it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070607 Minefield/3.0a6pre also. I'm going to try an older build and see if I can figure out a regression window.

gavin, vlad and stuart: do you see the "inverted black box" cursor with that test case?

Yeah, I can reproduce the bug with that testcase (at least over RDP, not sure if that makes a difference - color depth difference, perhaps?).

> color depth difference, perhaps yes! when my display is set to 32 bits, I don't see this bug. But I do see it when set to 16 bit. Note, this is not a problem with firefox 2 in either setting.

Probably most likely a problem in nsWindow::SetCursor(imgIContainer* aCursor, PRUint32 aHotspotX, PRUint32 aHotspotY) in http://mxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp

I get a problems on OS/2, too, that may be related. I am so bold to add that here instead of opening a new bug... Here Minefield actually crashes when I move the cursor over the image of the testcase. This is because nsThebesImage::GetAlphaBits() just returns null. gfxImageFrame::GetAlphaData() does not check for that and so silently returns a NULL pointer in its first argument to the caller which in this case is nsWindow::SetCursor(). Adding a check in gfxImageFrame::GetAlphaData() like in this patch helps to prevent the crash here at least and even under 16bit depth I see no bad effects but that may be different on Windows.

We shouldn't be using GetAlphaData anywhere anymore.

Note: I only tested this with Google Maps on a) a Windows 2000 console running 32-bit colour b) a 16-bit Windows XP RDP session.

I am seeing this on a system with 32-bit color using a nightly build from 20070810, so the problem is NOT only on 16-bit color systems.

I also see this on an older nightly trunk build from 20070527. I see it on 2 systems, one with an ATI card in 32-bit color, and another with an nvidia card in 16-bit color. The part of the 32x32 rectangle that is supposed to be transparent is black. The part of the 32x32 rectangle that is supposed to be opaque white is sort-of-transparent, except that it is inverted in the color space, white appears black, black appears white.

Changing bug summary, since this is NOT only on 16-bit color systems. (sorry for the bug spam)

This may not work for others, and may only work for a short time.

Comment on attachment 276837 [details] [diff] [review] This fixes it for me Hmm, you really want stuart to look this over rather than me.

Comment on attachment 276837 [details] [diff] [review] This fixes it for me This fixes a cursor display regression affecting several video drivers.

Fix checked in.

I have filed Bug 393013 for the issues from comment 8 and comment 9.

verified. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082111 Minefield/3.0a8pre