Ctrl-Backspace should stop_at_punctuation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Wishlist
|
|||
firefox (Ubuntu) |
Won't Fix
|
Low
|
Mozilla Bugs |
Bug Description
Binary package hint: mozilla-firefox
In a typical GTK widget with a URL, pressing Ctrl-Backspace will erase up to the previous "/". This does not operate as expected in Firefox. Pressing Ctrl-Backspace in the URL field erases the entire URL.
To fix this, layout.
In Mozilla Bugzilla #190615, Joshbirnbaum-mozil (joshbirnbaum-mozil) wrote : | #20 |
->selection
In Mozilla Bugzilla #190615, Gilead-j (gilead-j) wrote : | #21 |
Similarly, double-clicking on 'max_size' in (int max_size); selects
'max_size);' instead of just 'max_size' so it's problem not only with parentheses.
In Mozilla Bugzilla #190615, Vdvo (vdvo) wrote : | #22 |
Unless I'm mistaken, this is working as designed. There is a hidden pref called
"layout.
Unix, allegedly in order to be consistent with normal Unix behaviour. If you
want word selection to stop at punctuation, set the pref to true. However, there
is also bug 193025 about this not working when you set that pref in your user
profile's prefs.js, so you currently need to change the default in <moz inst
dir>/defaults/
Resolving INVALID.
In Mozilla Bugzilla #190615, Gilead-j (gilead-j) wrote : | #23 |
I'm sorry but being an Unix user I can't see such behavior anywhere. Just
verified it in bash, xedit, gedit, joe and vim - all of them behave exactly as I
suggested Mozilla should. So I disagree that this bug report is invalid.
I believe the preference you specified should be changed for Unix.
Adding ability to edit this in preferences window could accompany this change
but I personally don't think it's necessary.
Regards,
Max
In Mozilla Bugzilla #190615, Rparenton (rparenton) wrote : | #25 |
Created attachment 138526
Patch to remove the overriding of the default stop_at_
This should do the trick. However, as Vaclav Dvorak stated in comment #5,
persuading Akkana that this is the normal behavior on Unix/Linux is the key to
getting this checked in.
In Mozilla Bugzilla #190615, Vdvo (vdvo) wrote : | #26 |
Comment on attachment 138526
Patch to remove the overriding of the default stop_at_
How about trying it in 1.7a and revert it back if too many Unix users start
complaining?
In Mozilla Bugzilla #190615, Akkana Peck (akkzilla) wrote : | #27 |
Comment on attachment 138526
Patch to remove the overriding of the default stop_at_
A straw poll on #mozilla (very small sample size) had about 70% of users being
against it (with varying degrees of vehemence) and the rest being neutral;
nobody was strongly for it.
I still stand by that bug 98546 comment 104: if you post to mozilla-unix and a
significant number of people speak up and say they want it, and/or (preferably
and) you special-case the urlbar (which probably means overriding a click
handler in browser.js or somewhere like that), I'll check it in. A couple of
people saying they want it isn't enough to change urlbar functionality to
require three clicks instead of two.
In Mozilla Bugzilla #190615, Malcolm-smith (malcolm-smith) wrote : | #28 |
I don't understand bug 98546 comment 18 ("Unix browsers typically don't stop at
punctuation (makes life difficult in the urlbar)") - when changing from Galeon
1.3 to Firefox 0.8 I found this a significant regression.
Editing actions done in the URL bar are different to actions carried out in
normal textboxes. Specifically, the url bar never contains spaces, so breaking
only on spaces while processing the ctrl-left/right keys is useless. Instead,
ctrl-left/right should stop at the common url delimiter characters (bug 98546
comment 30), allowing swift editing of the URL with the keyboard rather than
fiddly pinpointing of the mouse or character-at-a-time positioning with
left/right keys.
Life would be much easier in the url bar if this was the case.
I'm talking here only about the ctrl-left/right word-at-a-time navigation keys.
What gets selected on a double-click seems to me to be a separate and less
important issue.
Furthermore, apparently due to Bug 193025, I can't easily check to see if
changing the hidden pref makes life more comfortable.
In Mozilla Bugzilla #190615, Malcolm-smith (malcolm-smith) wrote : | #29 |
(In reply to comment #9)
> Furthermore, apparently due to Bug 193025, I can't easily check to see if
> changing the hidden pref makes life more comfortable.
In Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 ,
changing the pref to true with the about:config interface causes the left/right
keys, ctrl or not, to not move the caret at ALL in the url bar.
In Mozilla Bugzilla #190615, Jlquinn-us (jlquinn-us) wrote : | #30 |
Setting layout.
reasonably. *PLEASE* make this the default on Unix, or at least Linux. Having
it set false makes editing URLS nearly impossible. What purpose does that
setting serve?
With it set true, double clicking still grabs the whole URL, so that ability
isn't lost.
In Mozilla Bugzilla #190615, Akkana Peck (akkzilla) wrote : | #31 |
> With it set true, double clicking still grabs the whole URL, so that ability
> isn't lost.
For me, when I set that pref, doubleclicking in the urlbar stops at punctuation.
(I tried it with my normal profile in 1.7 RC 1, and with my debug build, mostly
default, in a current tree.) I wonder what's different about our setups? Can
you try it with a new profile, see if it's different, and maybe track down the
difference? If we could solve the urlbar doubleclick problem, I'd be much less
worried about making this change. Any comments from other testers?
In Mozilla Bugzilla #190615, Jlquinn-us (jlquinn-us) wrote : | #32 |
(In reply to comment #12)
> > With it set true, double clicking still grabs the whole URL, so that ability
> > isn't lost.
>
> For me, when I set that pref, doubleclicking in the urlbar stops at punctuation.
Sorry about that. I mean triple-clicking. I wasn't trying to say it's broken.
Rather, that it's still possible to select the whole url with the pref set to
true. Trying to convince the powers that be to change this :-)
In Mozilla Bugzilla #190615, Jo-hermans (jo-hermans) wrote : | #33 |
*** Bug 249656 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #190615, Jlquinn-us (jlquinn-us) wrote : | #34 |
What's the current status on this bug? Any chance of getting in before firefox 1.0?
In Mozilla Bugzilla #190615, Neilparis (neilparis) wrote : | #35 |
*** Bug 245708 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #190615, Jlquinn-us (jlquinn-us) wrote : | #36 |
It's a year later. Any thoughts on this?
In Mozilla Bugzilla #190615, 3-craig-7 (3-craig-7) wrote : | #37 |
Can we please see some action on this? After discovering the workaround to this
problem (which has niggled me for well over five years on mozilla and earlier
incarnations of netscape), I sent out a notes to other software developers I
know who are based on linux and have had several responses back of the form
"Man, that has been bothering me for ages as well. Thanks heaps for that little
gem."
The justification given for the current functionality is that it should be
"consistent with normal Unix behaviour". I'd be surprised to learn if there was
any consistent standard for anything to do with graphic user interfaces between
unix environments. Further, my experience is that this is incorrect anyway.
Certainly my builds of gnome-terminal and xterm don't work like this. It's
certainly very un-unix-like to cripple keyboard functionality so that you have
to use the mouse for something.
Further, regardless of what the truth of this situation is or isn't, I'd suggest
that it's up to projects with huge userbases like mozilla to set the pace
through good design rather than to reimplement poor functionality just because
that's how other programs have done it in the past.
The current default is poor for people with keyboard-centric usage. People who
want to edit their URL bar without using the mouse currently have the following
experience:
(1) Press ctrl+L
-> URL bar highlights
(2) Press right
-> caret moves to end of the line
(3) Hold down backspace or shift+arrow for several seconds to highlight the bit
you want to highlight and then hope you let go at the right time.
When you tweak layout.
default configuration on mac or Windows, the behaviour is like this:
(1) Press ctrl+L
-> URL bar highlights
(2) Press right
-> caret moves to end of the line
(3) Press shift+ctrl+left to highlight the words you want to change
-> this is much quicker and more precise.
If you try this second process under the linux build of firefox, it highlights
back to the start of the line - an effect that can already be achieved with
ctrl+shift+home (or with the initial ctrl+l to highlight the location bar).
This is an annoying obstacle for users who use firefox to browse API docs all
day every day. They know what the class names are and want to be able to adjust
a path ending with /java/util/
they don't want to have to lean on arrow keys every time they want to do it, or
reach across for the mouse and then play with the URL using that imprecise pointer.
The current default configuration is deficient. There are many users out there
who are annoyed by this and aren't aware that it can be fixed through
configuration. This in turn gives unix-on-the desktop a bad name because firefox
for Windows is perceived to be a better product than firefox for unix.
It may be that there needs to be a separate configuration set up for the URL bar
than from the rest of the application. My personal preference is for mouse
clicks to highlight words - you can always hold down the second click and then
drag the mosue to finish off the highlight and I've gotten used to that through
use of firefox...
In Mozilla Bugzilla #190615, Uriber (uriber) wrote : | #38 |
*** Bug 302277 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #190615, Elmar-ludwig (elmar-ludwig) wrote : | #39 |
*** Bug 313723 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #190615, Jens Bannmann (bannmann) wrote : | #40 |
*** Bug 176354 has been marked as a duplicate of this bug. ***
38 comments hidden Loading more comments | view all 114 comments |
Vassilis Pandis (pandisv) wrote : | #1 |
This is minor, but I would like to see it as a defalut as well.
Changed in firefox: | |
status: | Unconfirmed → Confirmed |
Daniel Musketa (daniel-musketa) wrote : | #2 |
Yes, that would be nice.
Peter de Kraker (peterdekraker) wrote : | #3 |
I'm sooooo irritated because of this bug. It drives me nut.
PLEASE change this, it is a very minor thing, but it's something that is very irritating in daily use.
Changed in firefox: | |
assignee: | nobody → mozillateam |
importance: | Undecided → Low |
Changed in firefox: | |
assignee: | mozillateam → mozilla-bugs |
71 comments hidden Loading more comments | view all 114 comments |
In Mozilla Bugzilla #190615, Flávio Etrusco (etrusco) wrote : | #75 |
1) I usually try very hard to be polite. Problem is "the Mozilla team" is one of the less transparent and less responsive in the open source community. I just HATE secrecy. And the status quo.
2) Thanks.
3) Moot. If you really think like this why did you change it in the first place?
4) Just wrong.
And then, yes, I love Linus Torvalds' "diplomacy". Unfortunately I'm not as respected or known as him =P
TBH I'm asking to be flamed into oblivion so I can just forget about Mozilla as an open source project and stop being laughed at when why try to paint it as an open project (which has a community).
And I couldn't help being impolite again, but... why don't you stand by your POV and worst yet take the heat that was never meant to you? (I hope it's clear that my "ire" was not ever directed at you, if it seemed otherwise, please accept my apologies.)
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #76 |
I'll post a patch once the urlbar binding from bug 366797 is in the tree.
71 comments hidden Loading more comments | view all 114 comments |
Francesco (francesco-monte) wrote : | #4 |
Hi, as my ctrl+backspace doesn't work, this bug is still open..
What is blocking it?
Francesco (francesco-monte) wrote : | #5 |
- patch-firefox-control-backspace Edit (298 bytes, text/plain)
little "patch" for /etc/firefox/
please, land it!
Alexander Sack (asac) wrote : Re: [Bug 50254] Re: Ctrl-Backspace does not work as expected | #6 |
On Sat, Jun 02, 2007 at 08:29:49AM -0000, Francesco wrote:
> little "patch" for /etc/firefox/
> please, land it!
>
> ** Attachment added: "patch-
> http://
>
What has this patch to do with bug title? If its about a different
issue, please open a new bug.
Thanks,
- Alexander
Francesco (francesco-monte) wrote : Re: Ctrl-Backspace does not work as expected | #7 |
sorry? this patch allows you to delete the string in the url bar piece by piece
it's not another issue!
Alexander Sack (asac) wrote : Re: [Bug 50254] Re: Ctrl-Backspace does not work as expected | #8 |
On Sat, Jun 02, 2007 at 09:02:40PM -0000, Francesco wrote:
> sorry? this patch allows you to delete the string in the url bar piece
> by piece
>
> it's not another issue!
>
Sorry, I mixed this up with a bug that is about backspace not going to
previous page in history.
Thanks,
- Alexander
description: | updated |
Alexander Sack (asac) wrote : | #9 |
What is default behaviour on KDE?
Francesco (francesco-monte) wrote : | #10 |
On KDE, ctrl+backspace delete word by word (tested on konqueror).
And in Windows, the official build "firefox2 setup.exe" comes with layout.
Francesco (francesco-monte) wrote : | #11 |
is there any probability to have this fixed, at least, in gutsy?
Francesco
Alexander Sack (asac) wrote : Re: [Bug 50254] Re: Ctrl-Backspace should stop_at_punctuation | #12 |
On Wed, Jun 06, 2007 at 07:23:08PM -0000, Francesco wrote:
> is there any probability to have this fixed, at least, in gutsy?
As its not actually a bug I cannot give a committment to do it atm.
Probably this should be discussed upstream to establish a general
consense.
- Alexander
Jay Camp (jayc) wrote : | #13 |
This has been opened for *four* years in Mozilla which is ridiculous. I only discovered this problem a year ago and inquired about it and they were very flippant about the whole thing. I was told "this is how Unix works." This is a usability bug. There has been a fix for it the entire time which is to change a one-line setting.
I've linked the upstream Mozilla bug.
Francesco (francesco-monte) wrote : | #14 |
i agree with you.
btw, the firefox used in ubuntu is already patched -- firefox_
so, who cares if we resolve a mozilla related issue in "our home" ?
fixing it is not only a way to show that "ubuntu rocks", and "mozilla sucks" (which is true, but we don't care it)
fixing it would create a real *pragmatic community* , not lost in bureaucracy made by people that say "won't fix, in unix every application doesn't do it, so we don't need it"
Changed in firefox: | |
status: | Unknown → In Progress |
Changed in firefox: | |
status: | Confirmed → In Progress |
62 comments hidden Loading more comments | view all 114 comments |
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #77 |
Created attachment 270107
patch v1
So the urlbar binding has landed ... not sure if it will backed out again though. However, for the moment here's a patch.
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #78 |
Created attachment 272151
simplified patch, updated to current trunk
In Mozilla Bugzilla #190615, L. David Baron (dbaron) wrote : | #79 |
Renominating for blocking given that the new text frame busted URL bar selection.
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #80 |
So this is already the default on mac (in Fx2 too), why should the url-bar behave differently on unix?
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #81 |
Mano: Because Linux users are used to select the URL with a double click. I think it was reached consensus over this in this bug: stop_at_
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #82 |
Ok, Ugh, so:
1. Any reason you're not using an <handler> here (likely with phase="capturing")?
2. I think this deserves a preference.
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #83 |
3. you should probably override this for SM unless you're fixing their bindings too.
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #84 |
Created attachment 272561
patch v2
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #85 |
Er, this behavior isn't desired on mac AFAICT.
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #86 |
Created attachment 272565
patch v2.1
right
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #87 |
What's the use case for doubleClickSele
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #88 |
If both #textbox and #urlbar define <handler event="mousedown">, the one defined in #textbox would be of no effect, right? That means that the code from the original #textbox handler would have to be duplicated, if you want me to use <handler>.
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #89 |
ok, sorry that I didn't catch that earlier :(, the addEventListener is better than moving this to textbox.xml (preferably with a nsIDOMEventListener implementation on the binding, but simple functions like you had in the first patch would work too).
Again, sorry for the extra-work.
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #90 |
Created attachment 273341
patch v3
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #91 |
Comment on attachment 273341
patch v3
r=mano
In Mozilla Bugzilla #190615, Mano-mozilla (mano-mozilla) wrote : | #92 |
you need moa on the xpfe/ change.
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #93 |
Comment on attachment 273341
patch v3
<NeilAway> dao: so, in other words nothing changes for us... I can't argue with that :-)
In Mozilla Bugzilla #190615, Jruderman (jruderman) wrote : | #94 |
*** Bug 389516 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #190615, L. David Baron (dbaron) wrote : | #95 |
Minusing my own blocking request in favor of bug 389421. (Not to say this shouldn't go in, just that it's not blocking.)
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #96 |
Would be nice if someone could check this in before the diff becomes completely useless. Please let me know if it's already too much out of sync.
I assume approval isn't needed here.
In Mozilla Bugzilla #190615, Mozilla (mozilla) wrote : | #97 |
Comment on attachment 273341
patch v3
seems we need approval1.9 to get that in at this stage?
In Mozilla Bugzilla #190615, L. David Baron (dbaron) wrote : | #98 |
Comment on attachment 273341
patch v3
Not needed for front-end.
In Mozilla Bugzilla #190615, Mozilla (mozilla) wrote : | #99 |
Checked in. Please watch out for regressions.
Checking in browser/
/cvsroot/
new revision: 1.192; previous revision: 1.191
done
Checking in browser/
/cvsroot/
new revision: 1.16; previous revision: 1.15
done
Checking in modules/
/cvsroot/
new revision: 3.685; previous revision: 3.684
done
Checking in suite/browser/
/cvsroot/
new revision: 1.65; previous revision: 1.64
done
In Mozilla Bugzilla #190615, Dao (dao) wrote : | #101 |
*** Bug 348787 has been marked as a duplicate of this bug. ***
Changed in firefox: | |
status: | In Progress → Fix Released |
In Mozilla Bugzilla #190615, Francesco (francesco-monte) wrote : | #102 |
wow, just 4 years and half
if is helpful, microsoft used 6 years to relase IE 7
86 comments hidden Loading more comments | view all 114 comments |
Cameron Braid (cameron-braid) wrote : | #15 |
Making this change doesn't have a negative impact on users who don't try to use this feature. However, for people that expect to use Ctrl-Backspace, or Ctrl-Left or Ctrl-Right to jump words in the address bar should be able to.
I agree that this default should be changed in gutsy, independent of discussion upstream.
87 comments hidden Loading more comments | view all 114 comments |
In Mozilla Bugzilla #190615, Jruderman (jruderman) wrote : | #103 |
*** Bug 404356 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #190615, martin (mbvlist) wrote : | #104 |
All right, so this is supposed to be fixed. I've moved to Firefox 3 beta (3.0b3pre, a build by Swiftfox) on Ubuntu 7.04. Love the browser, love the new bookmarks, but HATE the preferences.
doubleclickSele
Changed that setting to false, so now I have the behaviour I (and many of the comments above) want: singleclick places the cursor, doubleclick selects a word, and tripleclick selects the entire line (like everywhere in every other GTK2 application I know). What is so hard about changing a default?
In Mozilla Bugzilla #190615, Jo-hermans (jo-hermans) wrote : | #105 |
*** Bug 410475 has been marked as a duplicate of this bug. ***
88 comments hidden Loading more comments | view all 114 comments |
Jeff Abbott (fdivbug) wrote : | #16 |
I agree that this change should be the default on Ubuntu. As someone who uses multiple platforms this is quite irritating, and I'm glad to have at least found a solution I can use on my own thanks to this Launchpad entry. For what it's worth, this preference is set to true in both Windows and Mac OS X Firefox builds (except, of course, in Mac OS X the key sequence is option+delete instead of ctrl+backspace).
I don't know if we should be considering consistency with other Unix applications and platforms -- which seems to be Mozilla's point of view, and rightly so for them -- so much as consistency with other Ubuntu apps and other platforms with which many of us work on a daily basis. "Muscle memory" accounts for a lot of my productivity, and I'd imagine I'm not alone in this.
Alexander Sack (asac) wrote : | #17 |
On Fri, Jan 04, 2008 at 04:12:46PM -0000, Jeff Abbott wrote:
> I agree that this change should be the default on Ubuntu. As someone
> who uses multiple platforms this is quite irritating, and I'm glad to
> have at least found a solution I can use on my own thanks to this
> Launchpad entry. For what it's worth, this preference is set to true in
> both Windows and Mac OS X Firefox builds (except, of course, in Mac OS X
> the key sequence is option+delete instead of ctrl+backspace).
>
> I don't know if we should be considering consistency with other Unix
> applications and platforms -- which seems to be Mozilla's point of view,
> and rightly so for them -- so much as consistency with other Ubuntu apps
> and other platforms with which many of us work on a daily basis.
> "Muscle memory" accounts for a lot of my productivity, and I'd imagine
> I'm not alone in this.
>
in the long run we will always stick to the behaviour that mozilla.org
chooses. this one is not an exception
affects ubuntu/firefox
status wontfix
- Alexander
Changed in firefox: | |
status: | In Progress → Won't Fix |
Jeff Abbott (fdivbug) wrote : | #18 |
Thanks, at least, for the explanation, Alexander.
87 comments hidden Loading more comments | view all 114 comments |
In Mozilla Bugzilla #190615, Bugmail-a (bugmail-a) wrote : | #106 |
One remaining issue for this—on Mac, at least—is that the underscore should not be considered punctuation. This is discussed in bug 393227 which depends on bug 190615.
In Mozilla Bugzilla #190615, Bugmail-a (bugmail-a) wrote : | #107 |
Er, make that, “depends on bug 196175.”
Changed in firefox: | |
importance: | Unknown → Wishlist |
In Mozilla Bugzilla #190615, Dan-256 (dan-256) wrote : | #108 |
Not to reopen a long dead, thread, but...ok, that's what I want to do.
It seems that this is broken on unix again. Double clicking selects the whole URL. The default for:
browser.
on Unix, is true. This means that double clicking doesn't stop at punctuation, because it doesn't stop at all, it just selects the whole URL. So was this whole bug for nothing?
According to this wiki:
http://
The behavior was changed to restore "double click selects all" on Unix. But then, how can one double click to select a word? In windows, the default is different, meaning that double clicking to select a word works.
The wiki states that it required "triple clicking" to select the URL. In windows, single clicking selects the URL. Should the same default be considered for Unix? Even if not, though, there should be a way to select individual words in the URL.
Again, what was the point of having the "stops on punctuation" setting if not to enable selection of "words"?
In Mozilla Bugzilla #190615, Soshial-reg (soshial-reg) wrote : | #109 |
I confirm Dan's words that it is still not default for firefox 10.0.2 on opensuse 11.2 64bit.
In Mozilla Bugzilla #190615, Cratuki (cratuki) wrote : | #110 |
Seen on Ubuntu 11.
There's a difference to previous behaviour. Selecting the URL bar with the keyboard (ctrl+L) allows the user to navigate around that bar stopping at punctuation (ctrl+left, ctrl+right). But a double mouse-click highlights the whole URL rather than words with in.
Triple-
Double-click being a unix standard remains a weak argument. Chrome for linux uses double-click to highlight word, triple-click to highlight all. i.e. the same behaviour as in firefox on osx and win32.
In Mozilla Bugzilla #190615, martin (mbvlist) wrote : | #111 |
Apparently nobody that has rights can be bothered to fix this, or even reopen the bug (RESOLVED FIXED no longer matches the status).
In Mozilla Bugzilla #190615, Bzbarsky (bzbarsky) wrote : | #112 |
This bug is about general selection behavior. Comment 89 and following is about urlbar selection, which explicitly overrides the default selection behavior. So they have nothing to do with this bug, which is in fact RESOLVED FIXED. You can test it by double-clicking "foo" in this text:
This.is.foo.stuff
and seeing whether it's just "foo" that's selected or the whole string.
In Mozilla Bugzilla #190615, Jm-leddy-x (jm-leddy-x) wrote : | #113 |
This somehow just bit me as well. I actually want the default unix behavior that requires a tripple click to select the entire address bar. Somehow doubleClickSele
http://
On Linux, I have the default of both singleClickSele
Is there another bug to request that Linux default to both being false, despite the expectation on other OSes?
In Mozilla Bugzilla #190615, Jm-leddy-x (jm-leddy-x) wrote : | #114 |
BTW I'm relatively confident that windows by default double click selects the whole text, since I'm frequently frustrated by expecting Linux behavior and getting something else. I'm not sure what the default of IE, chrome, Firefox etc is in the urlbar but I don't think it should really matter, because linux (unix?) users have a different expectation.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030125
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030125
Too much text is selected in source preview window when clicked on a word in
parentheses.
Eg.:
clicking on 'func' in class="func" selects entire phrase instead of just 'func'
clicking on '0000ff' in color="#0000ff" selects entire phrase instead of just
'0000ff' or '#0000ff'
Reproducible: Always
Steps to Reproduce:
1. Open page preview window or any page with text in parentheses
2. Click on text in parentheses
Actual Results:
Entire phrase is selected.
Expected Results:
Only text in parentheses should be selected.