269 bytes, text/html
1.05 KB, patch
|Details | Diff | Splinter Review|
2.49 KB, patch
Stuart Parmenter: review+
Stuart Parmenter: approval1.9+
|Details | Diff | Splinter Review|
270 bytes, text/html
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.
11 years ago
Summary: inverted cursor? at maps.google.com → inverted "black box" cursor at maps.google.com when display set to 16 bits color depth
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
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
Created attachment 270623 [details] [diff] [review] 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.
We shouldn't be using GetAlphaData anywhere anymore.
Created attachment 276837 [details] [diff] [review] 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.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #276837 - Flags: review?(vladimir)
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)
Summary: inverted "black box" cursor at maps.google.com when display set to 16 bits color depth → inverted "black box" cursor at maps.google.com on some systems
Created attachment 277015 [details] another demo with darker background to show inversion 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.
Attachment #276837 - Flags: review?(vladimir) → review?(pavlov)
Comment on attachment 276837 [details] [diff] [review] This fixes it for me This fixes a cursor display regression affecting several video drivers.
Attachment #276837 - Flags: approval1.9?
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
verified. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082111 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9 M8
You need to log in before you can comment on or make changes to this bug.