Closed
Bug 90587
Opened 23 years ago
Closed 15 years ago
clickSelectsAll should not trigger on task switch if textbox already had focus (url bar selected unnecessarily when switching windows while editing)
Categories
(Toolkit :: UI Widgets, defect, P4)
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
People
(Reporter: jruderman, Assigned: dao)
References
Details
(Keywords: access)
Attachments
(1 file, 1 obsolete file)
884 bytes,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
Steps to reproduce: 1. Click on the location bar. (Result: URL is selected) 2. Click on the location bar again. (Result: location bar is focused but not selected) 3. Switch to another app and back using the mouse or Alt+Tab. Result: the entire URL is selected. Expected: insertion point or selection should be the same as when I left the window. IE also has this bug, and I run into it several times a week while using IE. (Blake: you did an amazingly accurate job of copying IE's bugs when you helped us copy this feature.) Suggested fix: use onclick instead of onfocus for clickSelectsAll. This will break the case of tabbing to the location bar until bug 28583, "Focusing text widget (except on click) should select widget", is fixed, but won't affect Ctrl+L.
hrm. this also happens to the run dialog w/ xmouse. I'm not sure i consider this a bug. nc4's behavior is to set focus to _content which is annoying. AIM signon behaves like run. This appears to be the win32 standard behavior. steps: run aim w/ no network or MyAim>switch screen name. click in the middle of your screen name. change apps. a bit more info from terminal services client. if the box is a listbox you'll select all, if it's an editbox you won't. the urlbar is clearly a listbox. AIM of course is broken, if you try leaving focus in the password field it will wonder to the screenname field (select all) -- anyone want to file a (ns internal) bug for that ;-?
after thinking about it i guess we should rename it to focusSelectsAll since that's what the behavior really is and should be ...
Comment 3•23 years ago
|
||
No, focusSelectsAll is bug 28583 and should apply to all text fields, not just the address field.
Comment 5•23 years ago
|
||
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
Reporter | ||
Comment 6•21 years ago
|
||
*** Bug 199988 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 7•21 years ago
|
||
esj@harvee.org said on mozilla-accessibility@mozilla.org that this breaks NaturallySpeaking 6.1, which temporarily takes focus from applications. "If I dictate a URL and try to correct a word, when focus returns to the URL window, the entire URL is selected and the correction overwrites what I have previously spoken."
Keywords: access
Comment 8•21 years ago
|
||
Not sure what the status of the bug listed here is or if I'm in the right place but I have a comment. Firebird 0.7 on Linux, single-clicking the location bar selects EVERYTHING. The entire URL. I HATE HATE HATE that, it is NOT proper UNIX behavior, that is Win32 behavior. I ought to be able to single-click anywhere in the location bar to place the I-beam where I want it so I can edit things; double-clicking should select everything.
Reporter | ||
Comment 9•21 years ago
|
||
Chris: you're not in the right place.
Comment 10•19 years ago
|
||
I believe the simplest fix for this is to remove the 'onfocus' handler from the 'urlbar' element in browser.xul. As far as I can tell, this gets rid of the bug, but doesn't affect the rest of the location bar behavior. Nikitas Liogkas
Comment 11•18 years ago
|
||
WORKAROUND: The Autocomplete Manager extension (https://addons.mozilla.org/extensions/moreinfo.php?id=2300) includes a bugfix for this.
Updated•18 years ago
|
Assignee: hewitt → location-bar
Status: ASSIGNED → NEW
QA Contact: claudius
Updated•16 years ago
|
Product: Core → SeaMonkey
Assignee | ||
Updated•15 years ago
|
Assignee: location-bar → nobody
Component: Location Bar → XUL Widgets
Product: SeaMonkey → Toolkit
QA Contact: xul.widgets
Summary: clickSelectsAll should not trigger on task switch if location bar already had focus → clickSelectsAll should not trigger on task switch if textbox already had focus
Assignee | ||
Comment 13•15 years ago
|
||
Assignee: nobody → dao
Attachment #375813 -
Flags: review?(enndeakin)
Comment 14•15 years ago
|
||
Comment on attachment 375813 [details] [diff] [review] patch >+ // don't trigger clickSelectsAll when switching application windows >+ if (document.activeElement == this.inputField) This is a fragile check and it won't work at all after bug 178324 is done. What you actually want is a means of knowing if the element is within a toplevel window that is no longer active. I'll think about the best way to do this a bit.
Attachment #375813 -
Flags: review?(enndeakin) → review-
Assignee | ||
Updated•15 years ago
|
Assignee: dao → nobody
Updated•15 years ago
|
Summary: clickSelectsAll should not trigger on task switch if textbox already had focus → clickSelectsAll should not trigger on task switch if textbox already had focus (url bar selected unnecessarily when switching windows while editing)
Assignee | ||
Updated•15 years ago
|
Attachment #375813 -
Flags: review- → review?(enndeakin)
Assignee | ||
Comment 16•15 years ago
|
||
Comment on attachment 375813 [details] [diff] [review] patch this still seems to work, despite bug 178324
Comment 17•15 years ago
|
||
What I mean is that if your goal is to check only when the entire window is switched, the check here isn't sufficient. For instance, if the textbox is in a frame, document.activeElement will still be set to the textbox when switching to an element in another frame. Another example would be a textbox displayed in a tab. Switching tabs would not change the value of document.activeElement. I'm not saying the check here is incorrect, but I want to ensure that you are checking the right thing.
Assignee | ||
Comment 18•15 years ago
|
||
Alright, so this won't fix it for frames and content windows.
Attachment #375813 -
Attachment is obsolete: true
Attachment #375813 -
Flags: review?(enndeakin)
Attachment #383789 -
Flags: review?(enndeakin)
Comment 19•15 years ago
|
||
Comment on attachment 383789 [details] [diff] [review] patch v2 >+ window.constructor == ChromeWindow Isn't just using 'instanceof' sufficient here?
Attachment #383789 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 20•15 years ago
|
||
(In reply to comment #19) > (From update of attachment 383789 [details] [diff] [review]) > >+ window.constructor == ChromeWindow > > Isn't just using 'instanceof' sufficient here? For some reason, this gives me 'true': javascript:window%20instanceof%20ChromeWindow
Assignee | ||
Comment 21•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/914a46ad38b6
Assignee: nobody → dao
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9.2a1
You need to log in
before you can comment on or make changes to this bug.
Description
•