170861 - implement middle click paste to load URL for Windows

Status: RESOLVED FIXED

(Firefox :: General, enhancement)

Description

[Dan Morrison]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.2b) Gecko/20020924 Phoenix/0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.2b) Gecko/20020924 Phoenix/0.1

In normal Mozilla for Linux/X11, pasteing with the middle button into a "blank"
area of a web page will attempt to open the contents of the clipboard.  Phoenix
does not follow this behavior, but it would be very convenient if it did.

Reproducible: Always

Steps to Reproduce:
1.Double click on a url to enter it into the clipboard, such as
http://www.mozilla.org
2.Open a new tab so that you have a blank webpage rendered
3.Middle click to paste the url onto the blank webpage

Actual Results:  
Nothing ;)

Expected Results:  
The URL would be opened in the current window/tab as if you have entered it into
the location bar or via "Open Location..."

Comment 1

[Asa Dotzler [:asa]]

confirmed with a build from today. works in seamonkey so this is a
phoenix-specific problem. 

Comment 2

[André Dahlqvist]

*** Bug 171496 has been marked as a duplicate of this bug. ***

Comment 3

[Fabricio Campos Zuardi]

I don't think "it would be very convenient if it did". Implementing this would
make Phoenix behave different in linux and windows, including dataloss for
windows people migrating to linux, as described in
http://bugzilla.mozilla.org/show_bug.cgi?id=70498#c16

And as Mozilla is now, the tab is considered "blank area", causing bug 155851

Comment 4

[David B. Harris]

Okay, so what's the conclusion? (Sorry, I just filed bug 173132 - I didn't see
anything like this in the milestones, I must assumed that it _must_ have been
overlooked :)

Middle-clicking to paste&go, as it's described in bug 70498, *IS* terribly
convenient. Like somebody there said, being able to use my middle mouse button
was a big reason why I switched to *nix/X. Are there plans to enable either some
target-type thing (say, the status bar, or a big white and red target circle
toolbar item), or just use the URL bar instead?

Comment 5

[Asa Dotzler [:asa]]

*** Bug 173132 has been marked as a duplicate of this bug. ***

Comment 6

[Asa Dotzler [:asa]]

*** Bug 174786 has been marked as a duplicate of this bug. ***

Comment 7

[Jeremy Blosser]

Please see http://bugzilla.mozilla.org/show_bug.cgi?id=70498#c21 as rebuttal to
the discussion there and argument that this does need to be fixed on Phoenix.

This is literally the one and only regression I'm missing in Phoenix.  Otherwise
-- best [GUI] browser ever.

Comment 8

[Asa Dotzler [:asa]]

*** Bug 175361 has been marked as a duplicate of this bug. ***

Comment 9

[Shawn Lindsay]

This is really tripping me up.  Middle mouse button needs to  load url.  Middle
click on home should load home in a new tab (or window, as preffered).  Middle
click on back should load prior page in a new tab.  Middle click on current tab
should clone it, i.e. reopen it in a new tab.  Middle click on url in bookmark
should open bookmark in a new tab.  Middle click on throbber...etc.

Middleclicking on urlbar is not as good.  For one thing, the urlbar contents are
not replaced.  It is not consistent therefore with clipboard in X11, which
clears itself whenever something new is selected.  

The arguments about people migrating from MSWindows are wrong.  So many apps in
X11 rely upon the three button mouse.  Once you learn it, you don't want to go
back.  Phoenix is sticking out like a sore thumb with this behavior.  If it's
not the default it should be enabled through user.js--I tried, it doesn't work.

  

Comment 10

[Jeff Thieleke]

Attachment: Fix for Windows (at least)

Well, this is certain a quirky feature!  But I can see how it could be
something that, once you get used to it, you can't live without.

I confirmed this bug on Windows, and developed a patch to fix it.  I don't know
for certain if this will fix the bug on Unix, but it probably will.  If it
doesn't work on Unix, try changing the line:

  clipboard.getData(trans, clipboard.kGlobalClipboard);
to
  clipboard.getData(trans, clipboard.kSelectionClipboard);

kGlobalClipboard works on Windows, however.


An alternative to this feature is to add the following bookmarklet to your
Bookmark Toolbar:

javascript:q=document.getSelection();if(!q){void(q=prompt('Open
URL',''))};if(q){location.href='about:blank'; location.href=q;}

Select the URL you want, then click the bookmarklet.

Comment 11

[Jeff Thieleke]

Attachment: Also fix Control+Middle Click

I see that Control + Middle-Click (open clipboard contents in a new tab) was
also broken.

Comment 12

[Jeff Thieleke]

Attachment: Slight change to middle click paste

Ok, here is a proposal.  Many Windows users are used to being able to close a
tab using the middle button.  Many Unix users are used to being able to open a
link with the middle button in the content area.

So...would Unix users be up in arms if you could middle click to open a URL
anywhere *except* on an open tab?  This proposed patch prevents that, so middle
clicking on a tab will close it.  But if "middlemouse.contentLoadURL" is set to
true, middle clicking anywhere else (even on the tab bar, except for directly
on a tab) will open the URL on the clipboard.

This might bring harmony to both the Windows and Unix worlds...

Comment 13

[Jeremy Blosser]

According to bug 70498, what windows users expect is some kind of scrolling
behaviour when the middle click in a window... if that's accurate, I don't know
how likely "harmony" is.

Comment 14

[Jeff Thieleke]

> According to bug 70498, what windows users expect 
> is some kind of scrolling behaviour when the middle
> click in a window... if that's accurate, I don't know
> how likely "harmony" is.

Well, the middle-click in content area to open URL feature is only active if
"middlemouse.contentLoadURL" is 'true' (currently defaults to 'false'), so any
user, Windows or otherwise, has to manually enabled it.  I'm a Windows user, and
after playing around with "middlemouse.contentLoadURL" for a few minutes last
night, I just might get used to it.  OTOH, I have plenty of ways to scroll and I
definitely don't use the middle button to do so.

Comment 15

[Jeff Thieleke]

It looks like some of this was discussed in bug 171132 (resolved, WONTFIX).  Now
that there is a patch that fixes both bug 170861 and bug 171132, it might be
time to reconsider bug 171132...

Comment 16

[Asa Dotzler [:asa]]

Jeff, do you know why this works in the latest Mozilla builds and not in
Phoenix? Is your patch fixing something that Phoenix broke (or failed to fork)
or is it wholly new?

Comment 17

[Jeff Thieleke]

It appears that the only significant difference between Mozilla and Phoenix is
the line:

 data = data.value.QueryInterface(Components.interfaces.nsISupportsWString);

In Mozilla (and in my patch), it is:

 data = data.value.QueryInterface(Components.interfaces.nsISupportsString);

I don't see nsISupportsWString used anywhere else in Phoenix/Mozilla, so this is
likely some old code that was pasted into Phoenix's browser.js and wasn't tested.


Also, the line:

 clipboard.getData(trans, clipboard.kSelectionClipboard);

doesn't work on Windows.  I suspect that kSelectionClipboard is a Unix thing,
but apparently no one has tested any of these patches on Unix yet, so I don't
know.  I do know that with either of my patches, middle-click to open a copied
URL works on Windows.  If kSelectionClipboard is what is required on Unix, a simple:

#ifdef XP_WIN
clipboard.getData(trans, clipboard.kSelectionClipboard);
else
clipboard.getData(trans, clipboard.kGlobalClipboard);
#endif

should make this work on both Windows and Unix.

Comment 18

[Jeff Thieleke]

Er...I mixed that up, that last part should be:

#ifdef XP_WIN
clipboard.getData(trans, clipboard.kGlobalClipboard);
#else
clipboard.getData(trans, clipboard.kSelectionClipboard);
#endif

Comment 19

[jjkarppi]

Should this be marked FIXED? I'm using a recent nightly (2002-11-08) and
middle-click pasting a url to open it works well.

Comment 20

[Jeff Thieleke]

This is fixed for Unix (in browser.js v1.152 -
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&file=browser.js&rev1=1.151&rev2=1.152&root=/cvsroot)
but the rest of my patch that fixes it for Windows and synchonized the 'middle
click on tab' behavior is not.
 

Comment 21

[Asa Dotzler [:asa]]

This is working for linux as expected. middle click in content or on tab/tab bar
loads the clipboard URL. For a patch to be accepted, I think the current, and
expected, linux behavior needs to remain. 

also, does that "slight change" patch obsolete the "Also fix" patch? If so can
you mark the older patch as obsolete? Thanks.

Comment 22

[Asa Dotzler [:asa]]

This bug has morphed to into implementing new functionality for windows. Ideally
this bug would have been resolved and a new report filed for adding new phoenix
on windows functionality which would have cleared the way for verification of
the duplicates marked here.
Updating summary. Noting where the new bug starts and the old bug ends in the
status whiteboard.

Comment 23

[Mike Fedyk]

Whoo, yes!  Middle-Click in windoze!

This'll be one thing IE will probably copy from US!

What's holding this up?  Anything I can do to help?  (I'm a Windows/Linux user
of mozilla)

Comment 24

[Blake Ross]

You're welcome to make an extension that adds this functionality.

Comment 25

[Brant Gurganus]

VERIFYING obvious WONTFIX bugs.  Filter on firebirdWontFix to filter these bugs.
 I skipped a few that I'm unsure about from their summary and will manually go
through them.

Comment 26

[Jesse Ruderman]

I fixed this as part of bug 246719 by porting the patch from Seamonkey.