Mouse pointer "x" over Personal Toolbar dropdown menus

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Bookmarks & History
P4
trivial
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: Stanley Cline, Assigned: Brian Ryner (not reading))

Tracking

Trunk
mozilla1.0
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 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".
(Reporter)

Comment 1

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

Comment 2

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

Comment 3

16 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

16 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
happening.
(Reporter)

Comment 5

16 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

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

Comment 8

16 years ago
Still a cross on FreeBSD.

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

Comment 9

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

Comment 10

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

Comment 12

16 years ago
this bug still exists with RC1 
Mozilla
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 
(Assignee)

Comment 13

16 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?
(Assignee)

Comment 14

16 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

16 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.
(Assignee)

Comment 16

16 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

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

Comment 18

16 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

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

Comment 20

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

r=pavlov
Attachment #81755 - Flags: review+
(Assignee)

Comment 21

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

sr=blizzard
Attachment #81755 - Flags: superreview+
(Assignee)

Comment 23

16 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.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Whiteboard: [fixed on trunk]

Comment 24

16 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
(Assignee)

Comment 25

16 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

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

Comment 27

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

Comment 28

16 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

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

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

Comment 34

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

Comment 35

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

Updated

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

Updated

16 years ago
Attachment #81755 - Flags: approval+

Comment 36

16 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+
(Assignee)

Updated

16 years ago
Keywords: adt1.0.1

Comment 37

16 years ago
*** Bug 148349 has been marked as a duplicate of this bug. ***

Comment 38

16 years ago
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+
(Assignee)

Comment 39

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

Comment 40

16 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 
(Assignee)

Comment 41

16 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.
(Assignee)

Comment 42

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

Comment 43

16 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

Updated

16 years ago
Keywords: mozilla1.0.1+

Comment 44

16 years ago
VERIFIED Fixed branch and trunk builds
Status: RESOLVED → VERIFIED
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.