Highlighting text inputs acting strange.




19 years ago
8 years ago


(Reporter: jelwell, Assigned: joki)



Windows NT

Firefox Tracking Flags

(Not tracked)




19 years ago
I can't give an exact method for duplicating this problem, but I've verified on
#mozillazine during bugday that others have been seeing it also.
Currently I'm using build 2000011808 on winNT.

often i'll highlight something, then let go of the mouse button, but
          scrolling around on the page continues to highlight the text -
          especially noted in text input fields...

That's all I can really offer at this point.

Comment 1

19 years ago
This must be a "Selection" bug, possibly a DUP, but I'm not spotting one. 
Moving to that component.
Component: Browser-General → Selection
QA Contact: nobody → elig

Comment 2

19 years ago
Assigning to mjudge. I haven't seen this personally, so please do provide a 
reproducible test case if you encounter one, so that mike can fix it. thanks!
Assignee: nobody → mjudge

Comment 3

19 years ago
Here's a test case, it's really complicated; so I'm going to spell out what I 
think is happening. It appears that Mozilla is sending too many drag events to 
the various webshells open and the bottom webshell isn't receiving the 
mouse release; even though it initially got the drag...
If this isn't working for anyone, let me know. I tested it on winNT build 

Launch Mozilla.
<CTRL> N to open a new window.
Make sure you can see both applications at once. (but overlay them, so you can 
move your mouse between them without leaving mozilla)
Click into the Summary field of this bug. (anywhere in the middle is good).
Click onto the 2nd Mozilla window (click on the HTML where nothing is expected 
to happen - just to give Mozilla and the webshell focus. (especially not the 
Click the mouse down (Somewhere on the window that is also above the 1st 
Drag the mouse just a little (make sure the 1st window continues to be "under" 
the mouse).
release the mouse button.

*During the drag I think you have to actually _CROSS_ the point where you had 
left the pointer in the 1st window*
	-- by this I mean drag the mouse in around the 2nd window above and 
eventually across the X,Y coordinate of where you had last clicked in the 1st 
window (the Summary Field).
Now click back to the 1st window - again click into html where nothing is 
expected to happen.
Keywords: testcase

Comment 4

19 years ago
Mike, I'm putting this in m16 just so it gets in the queue.
Target Milestone: M16

Comment 5

19 years ago
*** Bug 32826 has been marked as a duplicate of this bug. ***

Comment 6

19 years ago
*** Bug 32826 has been marked as a duplicate of this bug. ***

Comment 7

19 years ago
I'm wondering if this is really event handling.  Several people have reported
that if they highlight text and move the moust pointer out to the window or
content area then release that it when the 'stickyness' happens.   Would that be
an event problem.

Comment 8

19 years ago
Yes, Asa, I think you're correct. Handing over to Event Handling.
Assignee: mjudge → joki
Component: Selection → Event Handling
QA Contact: elig → janc

Comment 9

19 years ago
adding self to cc: list, sorry for the spam.
*** Bug 33819 has been marked as a duplicate of this bug. ***

Comment 11

19 years ago
Bulk prioritizing bugs for correct milestones.
Target Milestone: M16 → M18

Comment 12

19 years ago
I think this is the same problem as 29697.
The "stickyness" even appears in the location bar. This seems to be a pretty
universial problem.

Comment 14

19 years ago
I agree with simon.

*** This bug has been marked as a duplicate of 29697 ***
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 15

19 years ago
Verified duplicate.
You need to log in before you can comment on or make changes to this bug.