Closed
Bug 57317
Opened 24 years ago
Closed 24 years ago
Middle button on blank area opens clipboard contents as URL in current window
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: niall, Assigned: akkzilla)
References
Details
Attachments
(2 files)
9.25 KB,
image/png
|
Details | |
1.09 KB,
patch
|
Details | Diff | Splinter Review |
When clicking the middle button on a blank area (non HREF) in a document,
mozilla attempts to open whatever is in the clipboard.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
I believe this is a feature. Netscape 4.x did this, and a number of people like
it very much and rely on it. This is a Unix-only behavior, since you are
effectively pasting the clipboard into the browser and the only reasonable thing
to try to do on such a paste to a non-editable area is to open the contents as a
URL.
Reporter | ||
Comment 3•24 years ago
|
||
Netscape 4.75 under Linux/X11 does not exhibit this behaviour. It's pretty
unintuitive, if anything I would expect clicking the middle button on a blank
area to open up a new browser window with the _current_ page.
Comment 4•24 years ago
|
||
Interesting. Netscape 4.75 on my system (Linux, X11) exhibits this behavior as
have all versions back to 4.05 or so. I don't remember before then...
There is a way to override this behavior with X resources for Netscape 4.x;
perhaps this has been done on your system?
It is maybe a little unintuitive (I found it very strange at first) but it is
enormously faster than hitting C-l and pasting into the text field if you want
to open a URL that's in the clipboard. And there is no good way to put the url
from the clipboard into the URL bar, since highlighting the url bar clears the
clipboard....
Comment 5•24 years ago
|
||
I don't see this on NS4.75, but I do see it in linux 2000102009. This is not
only unintuitive, but really annoying. Everytime I hit the middle mouse button
whatever is in the clipboard is pasted as the url and searched for. I scroll
with my scroll wheel so accidental mouse presses in white space is normal for
me.
Furthermore, it also interferes with autocomplete. I was at bugzilla.mozilla.org
and I accidentally hit mouse3, then it pasted my clipboard into the url bar. I
closed and restarted mozilla, everytime I tried to type in bugzilla.mozilla.org
it kept inserting the clipboard contents!! I'm pretty sure this is a regression
because I have never noticed it before and I accidentaly hit mouse3 a lot!
I feel that mouse3 should only open a new window when it's over a link, and do
nothing otherwise ...
Comment 6•24 years ago
|
||
I think that having the scroll wheel also act as Mouse2 (middle button) was
probably the stupidest thing that mouse manufacturers ever did.
But this has been standard Netscape 4.x behavior on all the unix
(Linux/Irix/Solaris) systems I have ever used. As for its being a regression,
see bug 37030, which is all about how the middle mouse button should paste the URL.
Arguably, this behavior should be a pref. In that case, I suggest closing this
bug and opening one in which we request a pref for this behavior.
As for pasting into the URL bar, well, that's standard X behavior for
applications. Highlight selects, middle-click pastes. This can probably be
disabled by telling your X server that you have a two-button mouse.
Comment 7•24 years ago
|
||
I really don't mind if it is a pref or not, but it should definately NOT paste
into the location bar if I press mouse3 somewhere else ... if I press it in the
location bar then that's the expected behavior.
Comment 8•24 years ago
|
||
over to toolkit. is clipboard toolkit or apps? Is there a specific person that
handles clipboard stuff?
Comment 10•24 years ago
|
||
so this is really a duplicate of bug 24571 then?
Comment 11•24 years ago
|
||
*** Bug 58316 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
ok, this has been working for me the last few builds, the middle mouse button
now works like it should. WFM linux 2000103008.
Comment 13•24 years ago
|
||
reproter: do you see this on new builds?
Comment 14•24 years ago
|
||
I still see this on current builds (2000110221). It is really very irritating,
and I've never seen it on Linux or Solaris with extensive experience with
Netscape > 4. Asa, this isn't a dup of 24571. That bug is for middle clicks in
general. The problem here is that middle clicks <i>in a text field</i> should
paste. Middle clicks that occur not in a text field should not paste, and
instead they do, and to a weird and unintuitive location (the URL bar.)
Comment 15•24 years ago
|
||
adding blake. setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 16•24 years ago
|
||
Still seeing in new builds?
Comment 17•24 years ago
|
||
I still see it in 2000120306. Am re-summarizing to make the bug more clear.
Summary: Middle button (open new browser) on blank area opens clipboard? → Middle button on blank area opens new browser with clipboard contents as URL
Comment 18•24 years ago
|
||
It opens a _new_ browser? It does not just open the url in the window into
which you pasted?
Comment 19•24 years ago
|
||
Doh. fixing that.
Summary: Middle button on blank area opens new browser with clipboard contents as URL → Middle button on blank area opens clipboard contents as URL in current window
Comment 20•24 years ago
|
||
*** Bug 62759 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
over to XPApps.
Assignee: asa → vishy
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Comment 22•24 years ago
|
||
nav triage team:
Pref sounds like the best way to go, but don't think we'll have time during
beta1, marking nsbeta1-
Keywords: nsbeta1-
Comment 23•24 years ago
|
||
akkana/anthonyd, could this be a selection/editor issue...?
Assignee | ||
Comment 24•24 years ago
|
||
It's a pref (so that we can turn it off for Windows/Mac users; Unix Netscape has
always had this behavior, and it will continue to be the default on Unix). Read
the comment from Jesse Ruderman 2000-10-24 17:14. Suggest marking the bug WFM
and the people who don't like it can set the pref.
Comment 25•24 years ago
|
||
I'm home on vacation, so I can't state this with absolute certainty, but I'd be
willing to be a small amount of money and a large amount of pride that the
current behavior is /not/ the default behavior of NS 4.x under Unix (at least
Solaris and Linux, which is all I have experience with.) Whether or not I am
correct in that, it is a pretty irritating preference that really doesn't make
much sense- in every other sane app I've ever used, on any platform, attempting
to paste while you are not in a text entry field is a no-op. So, if that was
the 4.x behavior, then it was a bug in 4.x and mozilla, and if it is only
mozilla behavior then it is still a mozilla bug.
As far as marking WFM- I'm against that. I'm fine with leaving the preference
in there (I could see how people might find this useful, if a bit non-
standard), but the default behavior should be to leave this "feature" off and
let people turn it on if they need or want it for some reason. Otherwise, we
are making mozilla behave in a completely non-standard way by default. Since
the preference is not exposed by a GUI (and it is therefore hard to know how to
make it behave in the default manner) this is even more pressing, I believe.
Assignee | ||
Comment 26•24 years ago
|
||
It has always been the default behavior on Unix Netscape. Honest. Try it, and
first move your ~/.netscape/preferences.js and your .Xdefaults aside and do
something like xrdb -l /dev/null to make sure your X defaults are gone. I won't
take your money. :-)
Comment 27•24 years ago
|
||
*** Bug 64559 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
With the default settings on RH6.2 and Netscape Communicator 4.75, NC4.75 will
NOT paste text i've selected on the page into URL field when i click
middle-button. It WILL paste it if i move cursor to URL field and focus it, and
it WILL paste it into a form field if i focus that. I never manupulated any
settings for pasting under X or NC - it just works like described "outta the
box". So that is what i'm used to: No pastes lands unexpected places when i
middle-click on an empty space on a page.
What happens instead in 4.75 on RH6.2 if i have selected text and then middle
click somewhere on page, is that selection gets de-selected again. No paste occures.
If NC 4.75 or RH is somehow "pretuned" for the behaviour i observe, it should be
tuneable for mozilla as well. This does seem like an xp4 issue to me.
Comment 29•24 years ago
|
||
I agree with liv@duke.edu's comments drom 2001-01-02 22:26.
akk, I don't remember ever having seen this behaviour in 4.x Unix. It's not my
prefs:
[ben ben]$ cat .Xdefaults
*blinkingEnabled: False
*noAboutSplash: True
[ben ben]$
I won't publish my prefs.js here, but I am not aware of such a pref, so I
certainly didn't set it manually. I use the Redhat Netscape Comm. packages,
maybe Redhat configured it so by default, dunno.
I agree with luke that this behaviour is against all conventions and should be
off by default.
The prefs I saw do not help, because I need middle-click paste for pasting in
textfields etc.. It is the 'loading on paste on background' which is IMO broken,
not the middleclick paste (the latter just makes the former appear more often).
I filed a dup bug, there is a bit more discussion.
Especially, Moses Lei suggested to limit the drop-area to a special place, like
the URL-proxy icon. This would be the best of both worlds IMO, and much better
than a pref.
Comment 30•24 years ago
|
||
*** Bug 64559 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
just filed bug 64577 - a clue to some of the unexpected evil pastes one sees in
mozilla and not in 4.75
Comment 32•24 years ago
|
||
oops. testing, it seems the situation in 64577 does nothing.
Assignee | ||
Comment 33•24 years ago
|
||
Ah, from dark's comments in bug 64559 I finally see why some of you say you
don't see this in 4.x. In 4.x, if you copy in a browser window and middle-mouse
into the same browser window, the selection disappears and nothing happens. But
try selecting in another app (e.g. an xterm) and middle-mousing into the browser
window. That's the behavior so many of us have come to rely on in 4.x and
earlier versions.
As for the pref, sure, rename the pref to make it different from
middlemouse.click. That's completely trivial. I'll attach a patch to do that.
Of course, feel free to rename the pref if you don't like my off-the-cuff
"middlemouse.contentLoadURL". You're on your own for the pref UI, but if
someone wants to do it, here are the four middlemouse prefs and you might as
well include them all: middlemouse.paste, middlemouse.contentLoadURL,
middlemouse.openNewWindow, middlemouse.scrollbarPosition.
Assignee | ||
Comment 34•24 years ago
|
||
Assignee | ||
Comment 36•24 years ago
|
||
Okay, if people like the patch, I'll take this bug and check it in.
Assignee: vishy → akkana
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Comment 37•24 years ago
|
||
Um... should that new pref be false by default?
That is, if we check this in, will we get a slew of "pasting to open a url
stopped working" bug reports?
Assignee | ||
Comment 38•24 years ago
|
||
It's false by default in all.js, overridden to true in unix.js, just like
middlemouse.paste itself. So on by default on Unix, off on other platforms.
Assignee | ||
Comment 39•24 years ago
|
||
Anyone know who the right person is to sr this?
Comment 40•24 years ago
|
||
akk, try hyatt.
Comment 41•24 years ago
|
||
sr=hyatt
Assignee | ||
Comment 42•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 43•24 years ago
|
||
Ahhhh :))) "...giant leap for mankind". Been looking forward to this one!
user_pref("middlemouse.contentLoadURL", false);
in prefs.js works fine. End Of Headache.
Verified fixed, if I may. 2001-011021
Status: RESOLVED → VERIFIED
Comment 44•24 years ago
|
||
I would like to have this enabled on windows. Well before this bug was Fixed it
worked (a long time ago). Now I can not get it to work on any recent build. I
have set to true all four middlemouse.* prefs and it will not work for me.
Is there anything odd I must do to make this work under windows?
Assignee | ||
Comment 45•24 years ago
|
||
I recommend that you file a new bug on the fact that this is not working on
windows; that's a different bug from this one. I'm not sure who it should go to
(maybe the default owner for browser-general?). Post the new bug number here so
anyone who's interested can join the cc.
Comment 46•24 years ago
|
||
Comment 47•24 years ago
|
||
i tried disabling this in linux build 20010124 by putting
user_pref("middlemouse.contentLoadURL", false);
in my ~/.mozilla/user/..../prefs.js, and when that didn't work, also in
mozilla/defaults/pref/unix.js, but middle clicking in content area still tries
to open clipboard as an url.
am i doing something wrong?
Comment 48•24 years ago
|
||
Janne:
Make sure to quit mozilla *before* editing prefs.js manually
(do a ps also, and kill eventual mozilla-bin processes.)
If you modify prefs.js manually while moz is still running, the manually edited
changes are overwritten when moz exits.
So quit the app - edit .mozilla/Default/..../prefs.js
and paste in
user_pref("middlemouse.contentLoadURL", false);
Make sure the file ends with a linefeed - save - restart mozilla.
Now it should work.
Comment 49•24 years ago
|
||
*** Bug 67839 has been marked as a duplicate of this bug. ***
Comment 50•24 years ago
|
||
*** Bug 64599 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
*** Bug 52185 has been marked as a duplicate of this bug. ***
Comment 52•24 years ago
|
||
*** Bug 70498 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
*** Bug 75414 has been marked as a duplicate of this bug. ***
Comment 54•23 years ago
|
||
*** Bug 111148 has been marked as a duplicate of this bug. ***
Comment 55•23 years ago
|
||
*** Bug 127689 has been marked as a duplicate of this bug. ***
Comment 56•23 years ago
|
||
*** Bug 147088 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
For those of us frustrated by this feature, this fix would be easier to find if
the summary (either alternatively or additionally) included the expression
favoured by the UI (e.g. Edit/Preferences/Tabbed Browsing) - namely
'middle-click': e.g.
'Middle-click on blank area opens clipboard contents as URL in current window.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 58•20 years ago
|
||
I don't consider this fixed, at least while the behaviour is enabled by default.
A hidden pref is nice but it is only a workaround which most people will not
find. Please see my comments in bug 135884, comment 13. Perhaps we should make
bug 135884 which is currently open the tracking bug for this?
It has been reported many, many times: bug 52185, bug 57317, bug 62759, bug
64559, bug 67839, bug 70498, bug 75414, bug 85677, bug 96972, bug 107147, bug
111148, bug 111337, bug 127689, bug 135884, bug 147088, bug 147088, bug 171132,
bug 226747, bug 228453, bug 258757, bug 274773, bug 278290 ...
Comment 59•20 years ago
|
||
(In reply to comment #57)
> For those of us frustrated by this feature, this fix would be easier to find if
> the summary (either alternatively or additionally) included the expression
> favoured by the UI (e.g. Edit/Preferences/Tabbed Browsing) - namely
> 'middle-click': e.g.
>
> 'Middle-click on blank area opens clipboard contents as URL in current window.
I second that suggestion. It should still be disabled by default.
Comment 60•20 years ago
|
||
This is a standard graphical browser behavior on X and has been since at least
1996 (when I first used a browser on X). Further, it's correct. Middle-paste
should act essentially like drag/drop, and it does. If you don't like X
conventions, feel free to use a different window system with different conventions.
Comment 61•20 years ago
|
||
(In reply to comment #60)
> This is a standard graphical browser behavior on X and has been since at least
> 1996 (when I first used a browser on X). Further, it's correct. Middle-paste
> should act essentially like drag/drop, and it does. If you don't like X
> conventions, feel free to use a different window system with different
conventions.
This is horseshit. Just because X does something for 20 years doesn't mean it
shouldn't wake up and fix its usability problems.
Besides, what you say IS somewhat correcct, but ONLY when the actual clipboard
content is pasted into the ADDRESS BAR. The CURRENT behavior is trying to load a
URL from the clipboard no matter where the cursor is. THIS is WRONG, and it is a
TERRIBLE usability because it is not obvious what the hell is going on.
Comment 62•20 years ago
|
||
If this were a usability problem, I would agree with you that it should be
fixed. But it's not. In fact, it's a usability boon -- there is no other way
to easily load a url that was "copied" somewhere via highlighting it.
> but ONLY when the actual clipboard content is pasted into the ADDRESS BAR.
This is PRIMARY content, not CLIPBOARD content. And if middle-click happens
over the address bar, the text should be inserted at the click position, not
replace all the text in the address bar. Which brings us back to my earlier
point in this comment.
Again, I'm not sure why you're not complaining about the way drag and drop works
-- it works the same way as middle-click, which is how it should be. It sounds
like you have a very wrong mental model of PRIMARY as a clipboard where copying
and pasting happen, etc. That's not what it is. The drag and drop mental model
is much closer to the way things work.
Comment 63•20 years ago
|
||
(In reply to comment #62)
> If this were a usability problem, I would agree with you that it should be
> fixed. But it's not. In fact, it's a usability boon -- there is no other way
> to easily load a url that was "copied" somewhere via highlighting it.
Boris, it is a usability problem. It's been reported as a bug something like 22
separate times so far. Lots of people have complained, sometimes in very irate
terms. The problem is that it gets triggered by accident, with results ranging
from harmless-but-annoying to really bad (dataloss, security compromised).
I agree with the rest of your point, there should be another way to easily
accomplish the same task. Middle-click to replace url bar is the obvious one.
Comment 64•20 years ago
|
||
(In reply to comment #63)
> Middle-click to replace url bar is the obvious one.
Oh, and to address your point about middle-click equals drag-and-drop:
1. drag-and-drop text into the content area does nothing, it does not try to
load it as a url
2. drag-and-drop links into the url bar replaces the url bar and loads
3. drag-and-drop text into the url bar does nothing (not even paste)
I would be absolutely happy if middle-click behaved exactly the same way (except
for #3 which is probably a bug and should be changed to paste).
Comment 65•20 years ago
|
||
> The problem is that it gets triggered by accident
How so, exactly?
> 1. drag-and-drop text into the content area does nothing
It loads the URL if the text happens to be a URL in Seamonkey and Firefox. It
doesn't show a "URL is not valid" alert if it's not a URL (but in Firefox it
does a Google search on the text instead). If what you want is for middle-paste
to do the same, then that would be a separate bug, no?
> 2. drag-and-drop links into the url bar replaces the url bar and loads
Not in Seamonkey. If find this behavior in Firefox very counterintuitive (not
to say incorrect).
> 3. drag-and-drop text into the url bar does nothing (not even paste)
Not in Seamonkey. Please file bugs on the Firefox UI being broken as needed.
Comment 66•20 years ago
|
||
(In reply to comment #65)
> > The problem is that it gets triggered by accident
>
> How so, exactly?
By missing the target of a middle-click by one pixel, either when trying to open
link in new window/tab or when trying to paste into a form field. Both of those
are very common actions with predictable occasional misses. Please see the
comments to all the bugs I listed in bug 135884, comment 13.
> > 1. drag-and-drop text into the content area does nothing
>
> It loads the URL if the text happens to be a URL in Seamonkey and Firefox. It
> doesn't show a "URL is not valid" alert if it's not a URL (but in Firefox it
> does a Google search on the text instead).
No, I've verified that drag and drop text, urls or links into the content area
really does nothing in Firefox and Seamonkey (Firefox nightly build 2005-05-21,
Seamonkey 2005-07-01).
Comment 67•20 years ago
|
||
Trying to analyze and hyper analyze here is a waste of time. The point of the
matter is, most people find this behavior problematic, it startles them, it
surprises them (and so usability goes out of the window when this happens). This
should be an enough indication for the maintainers to nuke that "feature".
Comment 68•20 years ago
|
||
> By missing the target of a middle-click by one pixel
The same is true of most other UI actions when you miss the intended target
area. Menus, say. Or drag/drop.
> No, I've verified that drag and drop text, urls or links into the content area
> really does nothing in
It works just fine in a 2005-07-02-07 Seamonkey trunk build, as well as several
Firefox builds (nightly from 2005-07-02, debug builds from 2005-07-01) over
here. I'm not sure what you're testing and how to get this to not work. Just
dragging the contents of the URL bar of this window to another window's content
area loads this bug in that other window.
Eugenia, unless you have hard data that more people find this behavior confusing
than useful, please try to at least be polite, ok? Failing politeness, attemt
constructiveness (if you're suggesting removing the only sane way to load a link
in PRIMARY in a Mozilla window, then a replacement with similar affordance is
needed).
Comment 69•20 years ago
|
||
(In reply to comment #68)
> > By missing the target of a middle-click by one pixel
>
> The same is true of most other UI actions when you miss the intended target
> area. Menus, say. Or drag/drop.
Usually a miss results in nothing happening. Menus have histeresis, by the way,
for pretty much that reason.
> It works just fine in a 2005-07-02-07 Seamonkey trunk build, as well as several
> Firefox builds (nightly from 2005-07-02, debug builds from 2005-07-01) over
> here. I'm not sure what you're testing and how to get this to not work. Just
> dragging the contents of the URL bar of this window to another window's content
> area loads this bug in that other window.
Dragging the url bar contents is the only way that works. Dragging a link from
the content area does not work, and dragging text from one content area to
another does not work either, even if that text contains a url.
> Eugenia, unless you have hard data that more people find this behavior confusing
> than useful
I provided such data (the current count of people who have voiced an opinion in
against or in favor of this feature is 49 to 14), and also suggested a newsgroup
poll as a definitive way to settle this if people thought that was not good
enough. The problem is that all complaints have been very persistently ignored
or given the cold shoulder for a long time, so I can understand how politeness
can start to fray.
> then a replacement with similar affordance is
> needed
I agree absolutely, actually I am working on a patch that does just that. I
will post it to bug 70498 which seems like the right place for it.
Comment 70•20 years ago
|
||
> Dragging a link from the content area does not work
Works fine here... So does dragging text from this very textarea to a different
window. So clearly you and I are doing something different.
> the current count of people who have voiced an opinion
That's not data. That's advocacy. People who use the feature have no reason to
know about these bugs and no need to comment in them. Data would be a usability
study.
Again, this is a feature that browsers on Linux have had for a very long time.
Every single Linux graphical browser (Opera, Konqueror, Netscape 3, Netscape 4,
Mozilla) has it. If it's to be removed, there needs to be very good data
showing that it's harmful (anecdotal evidence really doesn't cut it in such
cases, I'm afraid) and an obvious migration strategy for all the current users
who are using this feature and have been doing so for years.
Comment 71•20 years ago
|
||
(In reply to comment #70)
> People who use the feature have no reason to
> know about these bugs and no need to comment in them.
On the other hand I think most people never in their wildest dreams think this
could be a mozilla bug, let alone feature. Most would assume some type of
obnoxious or buggy javascript got triggered. Most never even figure out that
the site they end up on had anything to do with the contents of the clipboard
(see some of the comments along the lines of "ahh, so that's what it is" - and
those are generally pretty experienced users if they hang out here). So I would
argue the number of bug reports seriously underrepresents the problem.
> Data would be a usability
> study.
Please suggest a concrete plan that can actually be implemented to resolve this.
I don't have X amount of money to conduct a formal usability study, and I
imagine neither do you. I suggested some type of poll, or perhaps changing the
default behavior in the nighly builds and try to gauge the level of complaints
from that ;)
> Again, this is a feature that browsers on Linux have had for a very long time.
Is it documentated anywhere in mozilla? (Not anywhere I could find) If not,
what makes you think many people know about it?
> If it's to be removed, there needs to be very good data
> showing that it's harmful (anecdotal evidence really doesn't cut it in such
> cases, I'm afraid) and an obvious migration strategy for all the current users
> who are using this feature and have been doing so for years.
It's not to be removed, just disabled by default. I am honestly not sure how to
handle upgrades, but I think if there was a pref for middle-click-replace-urlbar
and the release notes said upgrading changes middleclick.contentLoadURL to false
and sets middleclick.replaceURLBar to true, that might be reasonable.
Assignee | ||
Comment 72•20 years ago
|
||
In exchange for removing a feature that many linux users depend on heavily,
you're proposing to replace it with a new pref which would remove yet another
important feature, the ability to paste text at a specific place in the urlbar?
If the problem is that it's too hard to discover the hidden pref, write some
documentation or lobby for exposing the pref. We've had enough functionality
regressions as it is; no need to seek out new ones.
Comment 73•20 years ago
|
||
(In reply to comment #72)
> In exchange for removing a feature that many linux users depend on heavily,
> you're proposing to replace it with a new pref which would remove yet another
> important feature, the ability to paste text at a specific place in the urlbar?
Not exactly, the replace will only work if the urlbar is not already focused.
Left-click+middle-click will always insert at a specific place, middle-click on
an unfocused urlbar will replace.
> If the problem is that it's too hard to discover the hidden pref, write some
> documentation or lobby for exposing the pref. We've had enough functionality
> regressions as it is; no need to seek out new ones.
That's part of the problem, and I certainly would like to expose the pref
(although that idea has been shot down before). The other part of the problem
is that *the default is wrong*.
Depends on: 331522
Comment 74•13 years ago
|
||
All I know is today in
Mozilla/5.0 (X11; Linux i686; rv:12.0a2) Gecko/20120309 Firefox/12.0a2 Iceweasel/12.0a2
I shall train myself to be very very very sure the pointer is really fully inside the textbox
before hitting that middle button.
You need to log in
before you can comment on or make changes to this bug.
Description
•