Mouse pointer "x" over Personal Toolbar dropdown menus

VERIFIED FIXED in mozilla1.0


17 years ago
15 years ago


(Reporter: sc1, Assigned: bryner)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fixed on trunk] [ADT3 RTM],custrtm-, URL)


(2 attachments, 1 obsolete attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020325
BuildID:    2002032508

The mouse pointer is an "x" instead of the usual arrow when selecting items in
Personal Toolbar dropdown menus (nested folders.)

Reproducible: Sometimes
Steps to Reproduce:
1. Set up a bookmark folder in the Personal Toolbar
2. Mouse over, but do not click on, a link in the folder

Actual Results:  You see an "x" where an arrow should be.  This is not
consistent; sometimes it's OK but most of the time it isn't.

Expected Results:  You should see an arrow not an "x".

Comment 1

17 years ago
Created attachment 76101 [details]
Screenshot of described behavior

Comment 2

17 years ago
Probably a symptom of bug 133265.
Depends on: 133265

Comment 3

17 years ago
My windows 3/27 build has this fixed and on bug 133265 the linux build from 3/28
is fixed so perhaps the submitter can check again?

Comment 4

17 years ago
I get the root window pointer (ie the X pointer) whenever I use a menu. This is
with build 2002032717. Somewhat disconcerning even after a few weeks of it

Comment 5

17 years ago
This is now partially fixed; with 2002032808 on Linux, when mousing over menus
the moused-over menu item is highlighted, but the pointer is still wrong (the
"x" instead of the arrow.)

Comment 6

17 years ago
Confirmed with 2002-04-11-09 on Linux using an old KDE as desktop.
Ever confirmed: true
wfm 200204112 Linux, KDE

Comment 8

17 years ago
Still a cross on FreeBSD.

Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9+) Gecko/20020412, build

Comment 9

17 years ago
Doesn't work for me. Build 2002041307, Linux, twm as the window manager. (no KDE
or gnome or anything fancy).

Comment 10

17 years ago
*** Bug 137448 has been marked as a duplicate of this bug. ***
Can someone please add the "regression" keyword?

Comment 12

17 years ago
this bug still exists with RC1 
Mozilla 1.0 Release Candidate 1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417

I think this bug should be fixed  BEFORE final version 1.0 

Comment 13

17 years ago
My guess is that this is a window manager issue... I don't see it with sawfish
1.0, but maybe that's a sawfish quirk.  blizzard, any ideas?

Comment 14

17 years ago
One possibility is that for whatever reason, the cursor for the popup is getting
set to whatever the root window's cursor is.  On sawfish, this is an arrow; on
other WM's, it's the X.

Comment 15

17 years ago
Bryner seems to be right. In fvwm when i set xroot pointer, same pointer
shows in menus:
xsetroot -cursor_name mouse
and i see three button mouse in all menus.

Comment 16

17 years ago
Created attachment 81585 [details] [diff] [review]
force setting the cursor for popup windows

Can someone who is seeing the problem try this patch?

Comment 17

17 years ago
Patch didn't seem to help, still wrong (root window's) pointer.

Comment 18

17 years ago
Created attachment 81755 [details] [diff] [review]
better patch

The previous patch didn't work because our internal state already indicated
that we were using the standard cursor.  This one should work.
Attachment #81585 - Attachment is obsolete: true

Comment 19

17 years ago
Yes this patch works ok. This would be good patch to 1.0 too.

Comment 20

17 years ago
Comment on attachment 81755 [details] [diff] [review]
better patch

Attachment #81755 - Flags: review+

Comment 21

17 years ago
Assignee: ben → bryner
Target Milestone: --- → mozilla1.0
Comment on attachment 81755 [details] [diff] [review]
better patch

Attachment #81755 - Flags: superreview+

Comment 23

17 years ago
Checked this in on the trunk.

Also nominating for nsbeta1.  As demonstrated by the comments here, this is a
fairly visible defect that can appear in a variety of configurations.  Leaving
the bug open until this is plussed or minused.
Keywords: nsbeta1
Whiteboard: [fixed on trunk]

Comment 24

17 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 25

17 years ago
I think we should consider this for RTM at least.  An "X" cursor creates the
false impression that the menu is somehow disabled.  When a user sees this,
we're going to look downright incompetent.  This is an extremely safe fix.  Why
would we not take it?
Keywords: nsbeta1- → nsbeta1

Comment 26

17 years ago
nsbeta1+/adt3-RTM per Nav triage team.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P4
Whiteboard: [fixed on trunk] → [fixed on trunk] [ADT3 RTM]

Comment 27

17 years ago
Closing the bug since this is checked in on the trunk.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 28

17 years ago
nope  it is not fixed... I still have CROSS when I click on File or 
any other pulldown menu

Mozilla 1.0 Release Candidate 2
Mozilla/5.0 (X11; U; RH6.2 Linux i686; en-US; rv:1.0rc2) Gecko/20020510
This it is not fixed in 1.0RC2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
Seeing this under SuSE Linux 7.2
RC2 wasn't released off the trunk.  This patch isn't on the 1.0 branch so it
isn't in RC2.
bryner, if you think this is 1.0 material (it looks safe enough) please drop
email to drivers asking to have it put in.
bryner, can you please try to get this into 1.0?
See comment #31 where blizzard says it should be safe for 1.0

Comment 33

17 years ago
this bug is not fixed... I still have CROSS when I click on File or 
any other pulldown menu

Mozilla 1.0 Release Candidate 3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523

Comment 34

17 years ago
*** Bug 137448 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
Adding custrtm- whiteboard comment; this bug has no customization impact.


17 years ago
Whiteboard: [fixed on trunk] [ADT3 RTM] → [fixed on trunk] [ADT3 RTM],custrtm-


17 years ago
Attachment #81755 - Flags: approval+

Comment 36

17 years ago
please checkin to the 1.0.1 branch (MOZILLA_1_0_BRANCH). you may need adt
approval for this considering you're a netscape employee.
Keywords: mozilla1.0.1+


17 years ago
Keywords: adt1.0.1

Comment 37

17 years ago
*** Bug 148349 has been marked as a duplicate of this bug. ***
adt1.0.1+ (on behalf ADT's behalf) for checkin to the 1.0 branch, pending
Driver's approval. Pls check this in asap.
Keywords: adt1.0.1 → adt1.0.1+

Comment 39

17 years ago
Checked in on the branch.
Keywords: fixed1.0.1

Comment 40

17 years ago
NOPE ...   this bug is not yet solved !! $%^grr&*(#@ the rest is censored

This BUG is NOT yet fixed ...   

Mozilla 1.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

REDHAT Linux 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 

Comment 41

17 years ago
LISTEN, we've been over this several times in the bug.  This fix did NOT make
the 1.0 release.  It will be in the 1.0.1 release.

Comment 42

17 years ago
*** Bug 130093 has been marked as a duplicate of this bug. ***

Comment 43

17 years ago
It works flawlessly for 

Mozilla 1.1a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610

Thanks to all


17 years ago
Keywords: mozilla1.0.1+

Comment 44

17 years ago
VERIFIED Fixed branch and trunk builds
Keywords: fixed1.0.1 → verified1.0.1
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.