If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Select list gets caret for mouse clicks in the same Y position even when X is outside

NEW
Unassigned

Status

()

Core
Event Handling
--
minor
13 years ago
4 years ago

People

(Reporter: Haakon Riiser, Unassigned)

Tracking

({testcase})

Trunk
x86
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

Go to http://bugzilla.mozilla.org/query.cgi and scroll down to the
"Bug Changes" box.  Click to the right of the select box that is
right under "where one or more of the following changed:", but at the
same height.  On Mozilla versions prior to 1.8 alpha 3, the correct thing
happens -- the select box does not get focus, since the mouse click missed
it.  On Mozilla 1.8a3 (and newer -- I've also tested nightly 20040819) the
select box gets the focus; when you try to scroll, it is the select box
that scrolls, not the page.

Reproducible: Always
Steps to Reproduce:
1. Go to http://bugzilla.mozilla.org/query.cgi
2. Click to the right of the middle select box in "Bug Changes"
3. Press Up/Down or use the mouse scroll wheel.  
Actual Results:  
The select box in "Bug Changes" scrolls because it incorrectly gets the focus.

Expected Results:  
The entire page should have scrolled, because the click was delivered to the
background, not the select box.
Worksforme with 1.8a3 on Win98....

Is this a GFX issue on Linux of some sort?
(Reporter)

Comment 2

13 years ago
I can reproduce it on Windows XP with 1.8a3, but I was wrong about
the bug appearing when using the mouse scrollwheel -- it only happens
when you scroll with the arrow keys!
Hmm... that worksforme as well...
(Reporter)

Comment 4

13 years ago
It's probably easier to use a picture to describe what I'm doing:

  http://folk.uio.no/hakonrk/mozbug256276.png

(Btw, I just noticed that the click has to be outside the Bug Changes frame.)
> (Btw, I just noticed that the click has to be outside the Bug Changes frame.)

Ah, ok.  There we go.

Mats, any idea what's up here?

Comment 6

13 years ago
This will be "fixed" by bug 254966 (which will change kbd scroll target from
caret to focus).  Perhaps the caret really ends up inside the list when the body 
is clicked in that area or nsEventStateManager::GetDocSelectionLocation() could
have a bug...  Anyway, the only way to see that something is wrong is by
scrolling and that symptom will disappear when bug 254966 is checked in
so I wouldn't worry too much over this one.
Assignee: nobody → events
Severity: normal → minor
Component: Layout: Form Controls → Event Handling
Depends on: 254966
QA Contact: core.layout.form-controls → ian

Comment 7

13 years ago
The problem as stated in comment 0 is not reproducible anymore (bug 254966
removed the method to reproduce it). The caret placement is still the same
though and a bit strange in my opinion - testcase coming up...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Summary: Select list gets focus for mouse clicks in the same Y position even when X is outside → Select list gets caret for mouse clicks in the same Y position even when X is outside

Comment 8

13 years ago
Created attachment 157757 [details]
Testcase (browsewithcaret must be on)

Updated

13 years ago
No longer depends on: 254966
Assignee: events → nobody
QA Contact: ian → events

Comment 9

4 years ago
I am interested to work on this bug and I would I like to know more details about this bug. I would also like to know where I should get started.
You need to log in before you can comment on or make changes to this bug.