Closed
Bug 405232
Opened 17 years ago
Closed 16 years ago
Duplicate URL by middle click on URL bar?
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
WONTFIX
Firefox 3
People
(Reporter: sciguyryan, Assigned: ehsan.akhgari)
References
Details
(Keywords: regression)
Attachments
(1 obsolete file)
Given the new addition of hiding the go button until there is a change in the url bar's contents it may be handy to make the url bar its self middle-clickable in order that people who used to use that feature of the go button to duplicate tabs can still use it.
Right now I do not believe that there is anything that can replace that feature.
Comment 1•17 years ago
|
||
You can drag the icon to the tabbar only this takes longer.
Also clicking the go-button when you want to reload the page is not possible anymore.
Updated•17 years ago
|
Blocks: 398020
Summary: Duplicate URL by muddle click on URL bar? → Duplicate URL by middle click on URL bar?
Comment 2•17 years ago
|
||
If I middle click on the URLbar now, the contents of my clipboard will be pasted into the locationbar. This feature is rarely useful for the locationbar (only when it is empty) so maybe it could be overridden.
Reporter | ||
Comment 3•17 years ago
|
||
Requesting a blocker - lets see if one of the higher devs will comment on this :)
Flags: blocking-firefox3?
Comment 4•17 years ago
|
||
Pressing Alt+Enter when the location bar has focus still works to duplicate the current tab, I think. An extra entry in the context menu for the tab bar would probably be more discoverable.
Using middle click to paste the current selection is a standard feature of text fields on Unix and really should not be broken for the location bar. And Mac users often don't have a middle mouse button.
Comment 5•17 years ago
|
||
My instinct is to
- use middle click, but maybe on the favicon?
- not add a context menu
Not blocking, could have some strange interactions ...
Flags: blocking-firefox3? → blocking-firefox3-
Comment 6•17 years ago
|
||
See also bug 298571.
Comment 8•17 years ago
|
||
This bug becomes really a problem when only one tab is open and the tabbar is hidden.
Assignee | ||
Updated•17 years ago
|
Severity: normal → enhancement
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 9•17 years ago
|
||
OK, after more thought, this seems to be a functionality regression. I'll be posting a patch shortly.
Severity: enhancement → normal
Keywords: regression
Assignee | ||
Comment 10•17 years ago
|
||
The behavior of this patch:
When middle-clicking on the URL bar text box, open the loaded page in a new tab if it's not empty. The middlemouse.paste pref overrides this behavior.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Attachment #301703 -
Flags: ui-review?(beltzner)
Attachment #301703 -
Flags: review?(mano)
Assignee | ||
Updated•17 years ago
|
Target Milestone: --- → Firefox 3 beta4
Comment 11•17 years ago
|
||
(In reply to comment #10)
> When middle-clicking on the URL bar text box, open the loaded page in a new tab
> if it's not empty. The middlemouse.paste pref overrides this behavior.
Do you have any idea what happens (if middlemouse.paste is off) in Linux/X?
BTW, can we get middle-click on Refresh button do the same? IMHO it makes much more sense.
Thanks Ehsan.
Assignee | ||
Comment 12•17 years ago
|
||
(In reply to comment #11)
> (In reply to comment #10)
> > When middle-clicking on the URL bar text box, open the loaded page in a new tab
> > if it's not empty. The middlemouse.paste pref overrides this behavior.
>
> Do you have any idea what happens (if middlemouse.paste is off) in Linux/X?
The new tab should load with the same URL as the current tab. There's nothing platform-specific in this patch. It only honors the middlemouse.paste pref, and that pref is turned on in *nix and off elsewhere by default, so *nix is not going to take benefit of this patch by default, but other platforms are.
> BTW, can we get middle-click on Refresh button do the same? IMHO it makes much
> more sense.
Yeah, it should be good for the case where that pref is true. It's trivial to implement, but let's wait for a ui-r from Beltzner to see if he deems this appropriate or not.
> Thanks Ehsan.
:-)
Comment 13•17 years ago
|
||
People who have the middlemouse.paste pref on and never use it on the locationbar (because it doesn't replace selected text) can't use this new function.
I have no idea how many people are using the middlemouse.paste function. It is only handy for empty fields. Maybe it should be turned off for the location bar field because it is rarely empty.
Comment 14•17 years ago
|
||
The new address-bar has two modes: First one is "enter-url" or "edit", which has the "Go" button on the far right. And the second one is "copy-url" or "view", which has the places "Star" button.
Maybe it's better to make the behavior of middle-click depends on the mode of the address bar. Here are the reasons:
- When the url field is empty, there's no need for duplication;
- When the url is edited, then we (most of the time) did something with keyboard, so we can use Alt+Enter;
- When the addr-bar is in view mode, there's no need to paste
Note: There's a beautiful usage here: Usually user wants to replace some part of the url, or just cut part of it. The second one can be done with "select+cut" actions. But for the first one, "select+cut" changes the addr-bar mode to "edit", then the middle-click will work as paste, so user can select and paste (just with mouse) the new text.
BTW, all of these don't cancel the request for middle-click on "Refresh" button. But there's an important difference. The old "middle-click on Go button" was like a copy'n'pasting the URL, so no POST data would be sent again. But the "Refresh" button does. I think we need the same behavior here too:
- Middle-click on URL do NOT send POST data;
- Middle-click on Refresh button DO send POST data (with warning, etc)
(Sorry for the long and complicated comment)
Comment 15•17 years ago
|
||
Comment on attachment 301703 [details] [diff] [review]
Patch (v1)
Please reset the review request once this has ui-review.
Attachment #301703 -
Flags: review?(mano)
Updated•17 years ago
|
Target Milestone: Firefox 3 beta4 → Firefox 3
Assignee | ||
Comment 16•17 years ago
|
||
Beltzner: ping...
Assignee | ||
Updated•17 years ago
|
Whiteboard: [has patch] [needs ui-review beltzner]
Comment 17•17 years ago
|
||
(In reply to comment #9)
> OK, after more thought, this seems to be a functionality regression. I'll be
> posting a patch shortly.
I think bug 263942 is a better way to deal with this.
Assignee | ||
Comment 18•16 years ago
|
||
After some more thought, I think Dão is right in comment 17. I'm resolving this as WONTFIX. If you think it's worth getting some attention, please re-open.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•16 years ago
|
Attachment #301703 -
Attachment is obsolete: true
Attachment #301703 -
Flags: ui-review?(beltzner)
Assignee | ||
Updated•16 years ago
|
Whiteboard: [has patch] [needs ui-review beltzner]
You need to log in
before you can comment on or make changes to this bug.
Description
•