Closed Bug 24325 Opened 25 years ago Closed 24 years ago

Highlighting text inputs acting strange.

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 29697

People

(Reporter: jelwell, Assigned: joki)

References

Details

(Keywords: testcase) 

[Bugday]
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.
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
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
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 
2000012520.

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 
border))
Click the mouse down (Somewhere on the window that is also above the 1st 
window.).
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
Mike, I'm putting this in m16 just so it gets in the queue.
Target Milestone: M16
*** Bug 32826 has been marked as a duplicate of this bug. ***
*** Bug 32826 has been marked as a duplicate of this bug. ***
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.

Yes, Asa, I think you're correct. Handing over to Event Handling.
Assignee: mjudge → joki
Component: Selection → Event Handling
QA Contact: elig → janc
adding self to cc: list, sorry for the spam.
*** Bug 33819 has been marked as a duplicate of this bug. ***
Bulk prioritizing bugs for correct milestones.
Target Milestone: M16 → M18
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.

I agree with simon.

*** This bug has been marked as a duplicate of 29697 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.