Closed
Bug 56472
Opened 24 years ago
Closed 21 years ago
focusing form element does not clear selected text in page
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
FIXED
People
(Reporter: djoham, Assigned: rbs)
References
Details
(Keywords: topembed-, Whiteboard: [T2])
Attachments
(1 file)
296 bytes,
text/html
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20001013 BuildID: 2000101306 If you have highlighted text (say after a user has double clicked on something) and then you set the focus to another element on the screen, the highlighted text is not unhighlighted. Since the focus is now on the new element, the highlighting should be gone. Reproducible: Always Steps to Reproduce: Open the attachment I'll include double click on the red line The double click will set the focus of the page to the text box. However,notice that the text that was highlighted when you double clicked is not un-highlighted when this happens. Actual Results: The highlighted text is not removed Expected Results: I would expect that the highlighted text would go away when the focus is set to the text box. IE renders this as I would expect. Why on earth would anyone care about this? I'm attempting to build a tree view control. When someone double clicks on a div, I do not want the highlighted text to still be highlighted. So I create a hidden text area and set focus to it after the double click. Works dandy in IE but not in Mozilla. I have a sorta Mozilla workaround by setting the display of the DIV to none and then block, but that only works until someone clicks somewhere else on the form. Then the highlighting comes back. grrrr Trivial bug.
Comment 2•24 years ago
|
||
event handling or html element I suppose. over to event handling first. confirmed with 101308 mozilla win32 build on NT4
Assignee: asa → joki
Status: UNCONFIRMED → NEW
Component: Browser-General → Event Handling
Ever confirmed: true
QA Contact: doronr → lorca
Comment 3•24 years ago
|
||
I talked to saari about this one. He kind of remembers it. I think we might be able to fix it by having the selection listener listen to focus messages and clear selection when an element gets focus.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 4•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Comment 6•24 years ago
|
||
Should fix this, it looks really bad. Moving to 0.9.2
Keywords: nsCatFood
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 7•24 years ago
|
||
It would probably save time if this bug was fixed at the same time as bug 36848.
Comment 8•24 years ago
|
||
This still looks bad but doesn't merit 0.9.2 vs my other bugs.
Target Milestone: mozilla0.9.2 → mozilla1.0
Updated•23 years ago
|
Blocks: advocacybugs
Updated•23 years ago
|
Keywords: mozilla0.9.4,
mozilla1.0
Comment 11•23 years ago
|
||
Just wanted to mention that Find/Replace and SpellChecking need to be kept in mind before turning off selection in the browser/composer content areas when focus is lost. If selection is turned off you won't be able to see what those dialogs are operating on. Or are we only talking about turning selection off when switching focus between elements within the same content window?
Comment 13•23 years ago
|
||
After speaking with saari and Mike Judge, I agree that highlighting and focus are not necessarily the same thing. Highlighting a link may not mean highlighted text should be unselected. (check behavior in NS 4.x, IE5) This should probably be closed as INVALID and shift "focus" so to speak, to bug 93521
Comment 14•23 years ago
|
||
per Ken's comment: resolving as INVALID
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Updated•23 years ago
|
No longer blocks: advocacybugs
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Comment 17•23 years ago
|
||
Fixing 36848 without fixing this bug would be strange, because text selected outside of the textarea would become unselected as soon as you pressed shift+left to select the character before the caret. I don't think this is invalid.
Severity: trivial → minor
Status: RESOLVED → REOPENED
OS: Linux → All
Priority: P3 → --
Hardware: PC → All
Resolution: INVALID → ---
Summary: focus not clearing highlighted text → focusing form element does not clear selected text in page
Target Milestone: mozilla1.0 → ---
Updated•23 years ago
|
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 19•21 years ago
|
||
I don't know if this is related to this bug, but: Ocassionaly when selecting typed text in a form, if you de-select the selected texy by clicking somewhere else in the field, or somewhere else on the bage, the un-selected text is still highlighted, and a non-blinking image of the curser is stuck where the curser was. Scrolling the affected area off the visible area of the page then back is the only way to return things to normal. I've only seen this bug in Mozilla for win32 later than 1.1, and Firebird for win32. I've seen this bug under all versions of windows later than win95 (haven't run win95 lately). Mostly i see this area on message boards run on phpBB or simalar software, but it more rarely also happens in other places.
Comment 21•21 years ago
|
||
Marking as FIXED.
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•