Closed Bug 22163 Opened 25 years ago Closed 24 years ago

on a mousedown focus change in text fields, selection must be collapsed

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: anthonyd)

References

Details

(Whiteboard: [nsbeta3+][p:3]fix in hand)

Attachments

(2 files)

Patch: select on click, collapse on blur, disabled by default
2.67 KB, patch
Details | Diff | Splinter Review
add a default value for the new pref
653 bytes, patch
Details | Diff | Splinter Review 
DESCRIPTION:  Double clicking in a (single-line) text input doesn't select the
contents when it's the first time one has clicked or double-clicked in that text
input.  This also effects the URL bar (each time it changes, or something...)

STEPS TO REPRODUCE:
 * load this page in mozilla
 * double-click on one of the text inputs that has text in it.

ACTUAL RESULTS:
 * if it's the first time you've clicked in that text input, the text won't be
selected, otherwise it will

EXPECTED RESULTS:
 * the text in the text input should be selected either way

DOES NOT WORK
CORRECTLY ON:
 * Linux, mozilla, 1999-12-18, 10:00 PST debug build

ADDITIONAL INFORMATION:
I haven't really tested textareas.  This could happen to them too.
Assignee: karnaze → buster
Reassigning to Steve.
Target Milestone: M14
minor functionality, setting to M14.
Status: NEW → ASSIGNED
marking potential beta1 bugs
Keywords: beta1
PDT-
Whiteboard: [PDT-]
moving non-PDT+ M14 bugs to M15.
Target Milestone: M14 → M15
Other products (IE 5, Communicator 4) select the text in the URL bar with a
SINGLE click in the field. I prefer this behaviour.


I absolutely hate the behavior of selecting the whole url with a single click
(and the Unix app never did this, thank heavens). If we turn this on, we should
definitely put it on a pref.  But that wouldn't be part of this bug anyway, I
wouldn't think (this one is on events getting through to the newborn webshell).
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
akkana:  are you, or someone else on the editor team, looking into rewriting the 
event handler for gfx edit controls?  if not, please reassign back to me
Assignee: buster → akkana
Status: ASSIGNED → NEW
Target Milestone: M16 → M18
Mike is rewriting the event handler right now.  I'll stay on the cc list, and if
this still happens and I have time, I may take the bug back from Mike.
Assignee: akkana → mjudge
Nominating nsbeta2 & clearing [PDT-] to trigger re-evaluation. The ability to 
select a form field's contents by double clicking is a pretty basic part of the 
UE of using HTML forms, and HTML forms are ubiquitous on the web and constantly 
used over the course of a day.
Keywords: nsbeta2
Whiteboard: [PDT-]
Putting on [nsbeta2-] radar.
Whiteboard: [nsbeta2-]
The behavior has changed (I assume with ender-lite), so that now, instead of
selecting nothing, we are selecting the part of the text to the left of the
clkci.  We should be selecting all of it on the first double-click.  Retitling
appropriately, and nominating for nsbeta3.
Keywords: nsbeta3
Summary: double-click in text input doesn't select the first time → double-click in text input only selects part the first time
the double clicking selecting to beginning of line is a dup of bug. 21090.  The 
highlighting of the entire url bar on focus is another issue. i am changing 
summary to reflect that.
Status: NEW → ASSIGNED
Keywords: beta1, nsbeta2 → correctness
Summary: double-click in text input only selects part the first time → URL bar should be highlighted on focus.
Whiteboard: [nsbeta2-]
Wait a sec, the URL bar should *not* be highlighted on focus.  Certainly not on
Unix anyway, because it clobbers the "clipboard".

But is the other part really a dup of bug 21090?  That seems to be mousewheel or
intellimouse or whatever it is stuff...
Summary: URL bar should be highlighted on focus. → URL bar should not be highlighted on focus.
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
ok then we need another lookandfeel crappy preff.  On windows the url bar is 
highlighted on focus.. dont ask me why, i think its stupid. so changing bug 
again to reflect the sometimes highlighting...
Summary: URL bar should not be highlighted on focus. → URL bar should be highlighted on focus on certain platforms
Whiteboard: [nsbeta3+] → [nsbeta3+][p:3]
we need a listener on windows only to highlight the url bar. sending to ben 
goodger for his expertise.
Assignee: mjudge → ben
Status: ASSIGNED → NEW
Please make this a pref, not an #ifdef, so that those of us who have to use
Windows now and then don't have to click twice (and vice versa for Windows users
using Linux).
OK, I don't like the behaviour proposed in the latter portion of this bug, and 
I'm not going to implement it. I think the original problem reported by dbaron 
has been fixed so closing as such.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 44728 has been marked as a duplicate of this bug. ***
reopening bug

Ben, what we need here is a js routine that will collapse the selection to the 
beginning when focus is lost in the URL location field. This should happen for 
all three platforms. Any other behavior requests should be opened under a new 
bug and assigned to the appropriate team. The unique behavior for windows will 
be opened as a new bug as an enhancement.

Changing summary to state that URL selection should collapse on loss of focus
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: URL bar should be highlighted on focus on certain platforms → URL selection should collapse on loss of focus
opened 55180 for window specific behavior
Question: if the selection collapses, doesn't that mean that when autocopy is
on, we lose the contents of the clipboard, so this would mean there would be no
way of copying the contents of the urlbar?  That would be a major functionality
loss; but if it just looked collapsed, but was really still in the clipboard,
that would be weird and unexpected since you wouldn't be able to see the
selection that you were about to paste.  Why is this better than a grey
selection?
Actually, bug 51580.
akkana,

what I had in mind with the js selection would just for the initial single click 
on to the url bar to collapse selection to the click point.  If you wanted to 
select the url to autocopy it, you should be able to still select it, and 
therefore autocopy it, i think.

Anthony

*** Bug 44728 has been marked as a duplicate of this bug. ***
reassigning to myself.

the only thing for url field is that on a focus change, the whole url bar needs 
to be selected.  I know everyone hates this, but IE does it, and 4.X does it, so 
end of story, Im sorry.

Now, this bug is for text fields we need on a mouse down change to a text field 
to collapse the selection to the mouse point.

anthony

ps. more details to come later
Assignee: ben → anthonyd
Status: REOPENED → NEW
Summary: URL selection should collapse on loss of focus → on a mousedown focus change in text fields, selection must be collapsed
okay, I have the fix for this, but in the process of fixing this, ben and I have 
discovered that javascript onblue event for xul fields does not work.  we went 
and talked to saari about this and he thinks that thisis a regression.  Im 
adding him and hyatt to the cc list, as the onblur event not working is a far 
more serious bug than this actual bug is.

anthony
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3+][p:3] → [nsbeta3+][p:3]fix in hand
as promised, here is hyatt to the cc list.
fix checked in.  if you click around like mad in the url bar, you will 
*occasionally* get some behavior that is not in tune with 4.x or IE.  I can 
reproduce this abberrant behavior without my changes, and after poking around 
I've determined that it is selection/event idiosynchracies (sp?) that are 
causing this.  These will be tracked down in time.

Anthony
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-13-08-M18 Commercial
- Win98     2000-09-13-08-M18 Mozilla
- MacOS86   2000-09-13-04-M18 Commercial
Status: RESOLVED → VERIFIED
Reopening.  What happens now on Unix is:
- On mousedown, selection is collapsed (correct)
- on focus out of the window then back in, select-all happens (incorrect)
Leave/Enter events shouldn't affect the selection, and select-all shouldn't
happen (at least on Unix) unless you ask for it.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
CCing self. This behaviour is very aggrivating on unix platforms, as it wipes
out the X selection. I think this should be considered a dogfood issue.

would everybody just take a deep breath and relax about this?  its only 
javascript and it will be corrected.

anthony

The Mac version never did that select the whole URL bar either.

Its *really* annoying. I always find myself double clicking in the URL bar in 
IE 5 on Windows to clear the selection that I don't want.

Why should this field stand out from every other one on the OS?

Just repeating bugs because they're in 4.X is not the answer. Spreading them to 
other platforms is even worse. (esp. Unix where its more than just annoying its 
destructive)

I'll take a chill pill and see what develops.
My suggestion to anthony was that we (1) move selectall to the button 1 click
handler rather than the focus handler, and (2) put it on a pref, disabled by
default.  (It's up for argument whether it should be enabled by default on
Windows, but certainly not on the other two platforms.)

I'm about to attach a patch which implements this.  Seems to work here on my
linux box. 
fix is in, added the following pref:
pref("browser.urlbar.clickSelectsAll", false); so the beahviour is off by 
default.

turn the pref on to see seamonkey behave like ie and 4.x on windows.
'props' to akkan ;-)

anthony
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Thanks a lot, this works. However, I'm getting some javascript warnings that
look like they may be related, so I'll ask here before opening a new bug. On a
focus/blur for the urlbar I now see:

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPref.GetBoolPref]"  nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/navigator.js :: URLBarLeftClickHandler :: line 2128"
 data: no]

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPref.GetBoolPref]"  nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/navigator.js :: URLBarBlurHandler :: line 2137"
data: no]

Does anyone else get that?

I get the same javascript messages on winNT 2000091505 as Decklin Foster

This is just a missing entry in the default prefs. I will attach a patch in a
second. Can someone please review the patch (just one line) and re-close the bug?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
i checked that in already, look at the original patch from akkana.  why you are 
not getting it i dont know, but i will look into it.

anthony

Oops, I should have read that patch fully ;-) I still don't see the change after
re-pulling the tree or in LXR, though. Not sure what's going on.
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#121
Bonsai doesn't show you checking in all.js.  Maybe something went wrong with the
checkin?  In any case, it looks like it needs to be checked in, 'cause it's not
there now.
*** Bug 52805 has been marked as a duplicate of this bug. ***
*** Bug 52939 has been marked as a duplicate of this bug. ***
*** Bug 52939 has been marked as a duplicate of this bug. ***
*** Bug 52977 has been marked as a duplicate of this bug. ***
*** Bug 53008 has been marked as a duplicate of this bug. ***
I've just checked in the default pref.  marking this fixed again.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Verifying on 
 -Windows 98 build 2000-09-22-08-M18
 -Linux RedHat6.2 build 2000-09-19-21-M18
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: