clickSelectsAll should not trigger on task switch if textbox already had focus (url bar selected unnecessarily when switching windows while editing)

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Toolkit
XUL Widgets
P4
normal
RESOLVED FIXED
17 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: dao)

Tracking

(Blocks: 1 bug, {access})

Trunk
mozilla1.9.2a1
x86
Windows NT
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

884 bytes, patch
Neil Deakin
: review+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Blocks: 62496

Comment 1

17 years ago
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 ;-?

Comment 2

17 years ago
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

17 years ago
No, focusSelectsAll is bug 28583 and should apply to all text fields, not just 
the address field.

Comment 4

17 years ago
reassign url bar bugs to new owner..
Assignee: alecf → blakeross

Comment 5

17 years ago
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
(Reporter)

Updated

16 years ago
Blocks: 28583
(Reporter)

Comment 6

15 years ago
*** Bug 199988 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 7

15 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

14 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

14 years ago
Chris: you're not in the right place.

Comment 10

13 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

12 years ago
WORKAROUND: The Autocomplete Manager extension (https://addons.mozilla.org/extensions/moreinfo.php?id=2300) includes a bugfix for this.
Assignee: hewitt → location-bar
Status: ASSIGNED → NEW
QA Contact: claudius
Product: Core → SeaMonkey
(Assignee)

Updated

9 years ago
No longer blocks: 343623
Duplicate of this bug: 343623
(Assignee)

Updated

9 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

9 years ago
Created attachment 375813 [details] [diff] [review]
patch
Assignee: nobody → dao
Attachment #375813 - Flags: review?(enndeakin)

Comment 14

9 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

9 years ago
Assignee: dao → nobody
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

9 years ago
No longer blocks: 230822
(Assignee)

Updated

9 years ago
Duplicate of this bug: 230822
(Assignee)

Updated

9 years ago
Attachment #375813 - Flags: review- → review?(enndeakin)
(Assignee)

Comment 16

9 years ago
Comment on attachment 375813 [details] [diff] [review]
patch

this still seems to work, despite bug 178324

Comment 17

9 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

9 years ago
Created attachment 383789 [details] [diff] [review]
patch v2

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

9 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

9 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

9 years ago
http://hg.mozilla.org/mozilla-central/rev/914a46ad38b6
Assignee: nobody → dao
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9.2a1
(Assignee)

Updated

4 years ago
Duplicate of this bug: 505464
You need to log in before you can comment on or make changes to this bug.