Closed Bug 96446 Opened 23 years ago Closed 22 years ago

Right-clicking location bar selects entire URL even if location bar already has focus

Categories

(SeaMonkey :: Location Bar, defect, P3)

Product:
SeaMonkey
Component:
Location Bar
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: theheards, Assigned: aaronlev)

References

Details

(Keywords: platform-parity, polish)

Attachments

(1 file)

In textbox.xml, on popushowing, checks to see if input field already has focus before calling focus() on it
1.02 KB, patch
deanis74
: review+
bzbarsky
: superreview+
roc
: approval+
Details | Diff | Splinter Review 
I'm using mozilla version 2001082203 in Windows 98, and when I tried to right
click to paste some text onto the current location, it selected the whole
location text, which isn't what I wanted.

Steps:
1.  Click on the status bar, so that nothing is selected (or alternatively, so
that less than the whole location is selected).
2.  Right click on the location bar to copy or paste something.

Expected:
The context menu comes up without changing the selection.

Actual:
The entire location is selected, then the context menu appears.

I couldn't find this bug reported yet, so I hope this isn't a dupe.  Not sure
which component this would be...
please try to pick components for bugs.
Assignee: asa → alecf
Component: Browser-General → URL Bar
QA Contact: doronr → claudius
confirming. I see this on Win98 2001090408

Steps to reproduce:
click in URL bar and select something.
right click on selection (to copy/paste whatever)
menu pops up and all text in bar is highlighted.
Status: UNCONFIRMED → NEW
Ever confirmed: true
adding to depends of bug 62496
Blocks: 62496
See also bug 78083, [clickSelectsAll] right-click on *unfocused* url bar should 
select contents.
*** Bug 99993 has been marked as a duplicate of this bug. ***
reassign url bar bugs to new owner..
Assignee: alecf → blakeross
*** Bug 103858 has been marked as a duplicate of this bug. ***
Severity: normal → major
Same result with using 'context menu key' instead of right-clicking.
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
*** Bug 100001 has been marked as a duplicate of this bug. ***
When the URL Bar becomes focused (via a mouse click from any button), it selects
itself.  I am not really sure this is a bug, as I don't see a strong case for
making an exception for right-clicking.  If I were to fix this, someone could
just as easily file a bug complaining that they intended to right-click the
urlbar and have it select the text so they could copy it.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Hi

I'm a voter for this bug and I wanted to give my 5 cents...
Behaviour i expect:
When I rightlick on the location bar when it was NOT selected, then it should 
select all text in it for copypasting it out from there (netscape 4 behaviour 
aswell), but when the cursor already IS in the location bar, a rightclick should 
just popup the context menu which I often use for example for pasting parts into 
the location bar when I'm too lazy to grab the keyboard...
So, selecting the text is okay, but NOT when the cursor already was in there 
since this prevents pasting using the context menu effectively.....

Thanks for listening

Matt
Thanks for pointing that out, Matt, I wasn't aware it selected everything even
when the focus was already there.  Reopening...
Severity: major → normal
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: --- → mozilla1.0
*** Bug 107740 has been marked as a duplicate of this bug. ***
This is definitely a usability issue and quite annoying if you're trying to
mouse around without touching the keyboard.

Is it possible to leave the selection alone for right mouse button clicks? i.e.
test the event from the handler and don't select if its not a left mouse button
click.
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: mozilla1.0 → Future
*** Bug 122388 has been marked as a duplicate of this bug. ***
*** Bug 127966 has been marked as a duplicate of this bug. ***
Summary: Right clicking on location bar selects entire location → Right-clicking location bar selection expands selection to entire URL
*** Bug 124083 has been marked as a duplicate of this bug. ***
Summary: Right-clicking location bar selection expands selection to entire URL → Right-clicking location bar selects entire URL even if location bar already has focus
*** Bug 120829 has been marked as a duplicate of this bug. ***
*** Bug 133474 has been marked as a duplicate of this bug. ***
*** Bug 133446 has been marked as a duplicate of this bug. ***
*** Bug 134736 has been marked as a duplicate of this bug. ***
adding keywords to get this on people's radars so the duplicates don't spin out
of control.

Does anyone see this on other OSs? (ones with ClickSelectsAll enabled?)
Keywords: mozilla1.1, nsCatFood, polish
One dupe from a Mac, different windows versions.

Setting Platform All, OS All, keyword pp
Keywords: pp
OS: Windows 98 → All
Hardware: PC → All
*** Bug 134736 has been marked as a duplicate of this bug. ***
I did some analysis and the problem seems to stem from the context menu. When
you right mouse on the location bar, focus momentarily is lost and regained.
This causes onblur & onfocus events to fire which causes everything to be
deselected and reselected.

The workaround is to set the "browser.urlbar.clickSelectsAll" pref to false.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam,

I just have tried your workaround suggestion re comment #26 of "this"
bug.  Great.  I now seem to have the expected behaviour of the right
mouse click.  Seem, as there is one other odd behaviour I now
observe, and would be a different bug.  I need to search the bug
database first to see if it has been reported already, and if not I
will open a new bug.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: .

iQA/AwUBPKt2N/LzhJbmoDZ+EQI7wwCgwdqV0NfgHMFsT7fJ++AfoItBm34AoLpp
yowf3RYh13fx/AdRlKHungWS
=qW4R
-----END PGP SIGNATURE-----

*** Bug 137267 has been marked as a duplicate of this bug. ***
*** Bug 137682 has been marked as a duplicate of this bug. ***
*** Bug 138053 has been marked as a duplicate of this bug. ***
I just attached a patch for bug 62495 that also addresses this bug.
*** Bug 141409 has been marked as a duplicate of this bug. ***
*** Bug 144550 has been marked as a duplicate of this bug. ***
As I mentioned before, I have a patch in bug 62495 that fixes this.  Would
anyone care to try it out and/or review it?
*** Bug 145183 has been marked as a duplicate of this bug. ***
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
*** Bug 153774 has been marked as a duplicate of this bug. ***
*** Bug 154519 has been marked as a duplicate of this bug. ***
taking
Assignee: hewitt → dean_tessman
Status: ASSIGNED → NEW
fixed on trunk with check-in for bug 62495
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
The real cause of this was spurious focus events caused by the context menu.
I'll file a new bug that shows how fixing that makes this bug easier to fix.
Hey, that would be great!  Those extra focus and blur events were a pain when I
was working through this.  In the meantime, at least right-click works properly now.
I've filed bug 155871 on the context menu focus event issue.
This should be reopened. 2002100710 trunk has this issue again.
Hrm, I see it too, using a build from Oct 6.  Neil, any idea why?
This applies to all textboxes; on one PC it even applies to form inputs :-(
So it's not specific to the URL bar.
It's definitely all XUL text boxes on my machine.  It sounds like this could
have been regressed by the fix to bug 28583.  Aaron, any thoughts?
Yes, this is my regression -- nice catch Dean. Right clicks for XUL textfields
must be handled in script, I'm not getting this behavior in HTML textfields,
which is what XUL textfields wrap.1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yes, it affects XUL textboxes, now that I've correctly rebuilt Mozilla I think
the line to blame is in textbox.xml (extract):
<binding id="input-box">
  <content context="_child">
    <children/>
    <xul:menupopup onpopupshowing="this.parentNode.firstChild.focus();

The call to focus() is autoselecting the text. Can we live without this? 
Forgive my ignorance, but shouldn't a focus event only place focus on a
particular widget? In the case of textboxes, focus should only place the cursor
inside of it. Autoselecting the text is bad. If Mozilla is autoselecting the
text of textboxes on focus, the bug is wherever that is happening IMHO. Please
ignore this if you meant "can we live without this" to apply to autoselecting
text instead of giving XUL textboxes focus.
Jerry, see bug 28583.

Neil, yeah -- I'm looking at that too. Removing the
parentNode.firstChild.focus() call fixes it, but I'm not 100% sure that's okay.

Maybe we should test to see if focus is there already, and it is, don't focus it
again.
Bug 28583 specifies that onclick should not trigger the autoselection of text.
The standard behavior of textfield widgets in Win32 is that a click does not
select the text, and tabbing into the field *does* autoselect the text. I
suppose that is the optimal solution here. URL bars are special cases where
users probably expect autoselected text onfocus even with click, but only the
first click.
Jerry, you are correct. That is the behavior we are trying to fix.
The click isn't the problem but the call to .focus() that selects the text.
patch forthcoming
Assignee: dean_tessman → aaronl
Status: REOPENED → NEW
Note, even just removing the focus() call completely from onpopupshowing worked
in my tests, because the right click focuses the the textbox anyway.
Neil, your patch to bug 155871 made a minor change to this part of textbox.xml.

-      <xul:menupopup onpopupshowing="this.parentNode.focus();
this.parentNode.doPopupItemEnabling(this);">
+      <xul:menupopup onpopupshowing="this.parentNode.firstChild.focus();
this.parentNode.doPopupItemEnabling(this);"

Do you recall why?
this is the menupopup element
this.parentNode is the containing box
this.parentNode.firstChild is the html <input> edit control
Comment on attachment 102588 [details] [diff] [review]
In textbox.xml, on popushowing, checks to see if input field already has focus before calling focus() on it

Sounds good.  r=me
Attachment #102588 - Flags: review+
*** Bug 174038 has been marked as a duplicate of this bug. ***
Comment on attachment 102588 [details] [diff] [review]
In textbox.xml, on popushowing, checks to see if input field already has focus before calling focus() on it

Just wondering whether it's more readable to put the focus handling code in the
doPopupItemEnabling method.
Comment on attachment 102588 [details] [diff] [review]
In textbox.xml, on popushowing, checks to see if input field already has focus before calling focus() on it

sr=bzbarsky
Attachment #102588 - Flags: superreview+
*** Bug 173933 has been marked as a duplicate of this bug. ***
*** Bug 175449 has been marked as a duplicate of this bug. ***
Should we try to get this regression fix into 1.2?
*** Bug 175580 has been marked as a duplicate of this bug. ***
(Hopefully) nominating for 1.2; does someone have to email drivers?
Keywords: mozilla1.1 → mozilla1.2
Comment on attachment 102588 [details] [diff] [review]
In textbox.xml, on popushowing, checks to see if input field already has focus before calling focus() on it

a=roc+moz for trunk
Attachment #102588 - Flags: approval+
checked in fix for regression.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
*** Bug 177654 has been marked as a duplicate of this bug. ***
*** Bug 178384 has been marked as a duplicate of this bug. ***
*** Bug 179335 has been marked as a duplicate of this bug. ***
*** Bug 182077 has been marked as a duplicate of this bug. ***
WFM with new nightly/win2k.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: