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.

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.

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.

Requesting a blocker - lets see if one of the higher devs will comment on this :)

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.

My instinct is to - use middle click, but maybe on the favicon? - not add a context menu Not blocking, could have some strange interactions ...

See also bug 298571.

This bug becomes really a problem when only one tab is open and the tabbar is hidden.

OK, after more thought, this seems to be a functionality regression. I'll be posting a patch shortly.

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.

(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.

(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. :-)

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.

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 on attachment 301703 [details] [diff] [review] Patch (v1) Please reset the review request once this has ui-review.

Beltzner: ping...

(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.

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.