383668 - inverted "black box" cursor at maps.google.com on some systems

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[(not reading, please use [e-mail] instead)]

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

Comment 1

[:Gavin Sharp [email: [e-mail]]]

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

Comment 2

[(not reading, please use [e-mail] instead)]

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.

Comment 3

[(not reading, please use [e-mail] instead)]

Attachment: simplified test case based on google maps

Comment 4

[(not reading, please use [e-mail] instead)]

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

Comment 5

[:Gavin Sharp [email: [e-mail]]]

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

Comment 6

[(not reading, please use [e-mail] instead)]

> 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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 8

[Peter Weilbacher]

Attachment: Add check to gfxImageFrame::GetAlphaData()

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.

Comment 9

[Stuart Parmenter]

We shouldn't be using GetAlphaData anywhere anymore.

Comment 10

[[e-mail]]

Attachment: This fixes it for me

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.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Attachment: another demo with darker background to show inversion

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

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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 16

[[e-mail]]

Comment on attachment 276837 [details] [diff] [review]
This fixes it for me

This fixes a cursor display regression affecting several video drivers.

Comment 17

[[e-mail]]

Fix checked in.

Comment 18

[Peter Weilbacher]

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

Comment 19

[(not reading, please use [e-mail] instead)]

verified.

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