68753 - middle click in directory listing

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[gordon.keith+mozilla]

Version: Mozilla 0.7 (Build ID: 2001010517) on linux
Mozilla/5.0 (X11; U; Linux 2.2.13 i686; en-US; 0.7) Gecko/20010105

open file:///some_directory/

If you double left click on a file it opens that file. - Correct

If you right click on a file and select "Open File in New Window" it opens the
file in a new window. - Correct

If you middle-click on a file you would expect it to open that file in a new
window, the same as middle-clicking a link. However, it pastes the current
buffer into the URL box - which is the standard behaviour when middle clicking
not on a link.

I think it would be better to treat a directory entry as a link rather than as a
non-link in this context.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Sounds like a good idea to me.  Over to xpapps gui features, ccing blake because
he did a lot of the other middle click stuff.

Comment 2

[Bradley Baetz]

Adding me to cc because I've been playing with the dir viewer lately. This
should be simple - I'll look at it after gopher lands.

Comment 3

[Blake Ross]

Bradley, this is indeed simple.  Do you want to take it or should I? 

Comment 4

[Bradley Baetz]

Oh, I forgot about this :) Feel free to take it.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

All platforms, since this is an XP feature. 

Comment 6

[Andreas Kunz]

This works now (2003012417 on Win2k).
Can't test on Linux because my installation does not like my middle mouse button...
But this old bug should probably be closed.

Comment 7

[Stephen Ostermiller]

Confirming fix on Linux, middle click on file or directory opens the file or
directory in a new tab (which is my preference).

Build: 2003011308 Redhat 7.3

Comment 8

[Andreas Kunz]

...and it opens in a new window if the "new tab" preference is *not* set.
-> WFM
Please reopen with explanation if this is still a problem somehow.

Comment 9

[Boris Zbarsky [:bzbarsky]]

as a note, this only works now because the XUL dirviewer was disabled in favor
of the HTML one....

Comment 10

[Andreas Kunz]

Oh well, unfortunately there is no direct reference to the XUL dirviewer in this
bug.
If the XUL viewer is still considered important or having a future, this bug
should be reopened - but with extended summary.
I'll leave it to you to decide.

Comment 11

[sairuh (rarely reading bugmail)]

v w4m.