414345 - Middle-click on favicon or content area produces confusing alert if there's no valid url in the clipboard

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Behnam Esfahbod [:zwnj]]

Middle-clicking on the site icon, I got this alert: "The URL is not valid and cannot be loaded."  I didn't know it's a feature, because it's new, and the test from clipboard is not actually pasted anywhere first.  User should know what "The URL" refers to.

Solutions:
- Show the clipboard text in the alert box;
- Paste it on the URL bar, then make an error if needed.

Note that this is a lot more confusing for Win users.

Comment 1

[Elmar Ludwig]

Just a few notes:

- This feature isn't new, it has been in Firefox since version 1.5.

- Middle clicking in the content area produces the same alert, if the pref
  "middlemouse.contentLoadURL" is true and autoscrolling is disabled, which
  are the default settings on Linux. See bug 85677 and bug 96972 for lots of
  discussion about this problem.

- Windows users won't see this unless they manually set "middlemouse.paste"
  to true in about:config, so I don't think it's a problem there.

Comment 2

[Elmar Ludwig]

See also bug 254714 about setting the address before the URL starts loading.

Comment 5

[Dão Gottwald [:dao]]

Attachment: fixup urls

Comment 6

[Dão Gottwald [:dao]]

Attachment: don't try to load clipboard content that's not a valid uri

I would largely prefer this solution, because middle clicks happen accidentally (esp. if you're used to autoscrolling from Windows or Mac), and replacing the current page with a random new one will probably be as annoying as the alert.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> Created an attachment (id=384399) [details]
> don't try to load clipboard content that's not a valid uri

I think I prefer this too, but I'm not sure there's a good reason to break the keyword-pasting functionality. You can avoid that by just passing the result of getShortcutOrURI to newURI right?

Comment 8

[Dão Gottwald [:dao]]

I did that in an intermediate step but discarded it...
Selecting "keyword param" from somewhere (static text from a web page? typed text in a text field but not the location bar?) and pasting it over the content area or the favicon (but not in the location bar) seems like a strange use case.

Comment 9

[scientus]

I cant replicate the favicon thing, as that just closes the tab.

However #6 fixes it for me. What is this keyword-pasting functionality? Perhaps doing keyword.enabled ie google search, from the middle clicks? I dont get any such functionality on Linux even when keyword.enabled;true and middlemouse.contentLoadURL;true .

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #9)
> I cant replicate the favicon thing, as that just closes the tab.

The location bar's favicon...

> What is this keyword-pasting functionality?

http://support.mozilla.com/kb/Smart+keywords

Comment 12

[Tchalvak]

Yeah, what this often means from what I've seen from using shiretoko is that:

when you're middle-clicking a link to open it in a new tab, and you miss, you get that disruptive error message instead of something that allows you to simply continue working.

Comment 13

[[e-mail]]

Fixed in Firefox 3.5.1~!

Comment 14

[Dão Gottwald [:dao]]

This hasn't changed in Firefox 3.5.1.

Comment 15

[[e-mail]]

Well a fix that was released must have fixed it. After I upgraded, I can not reproduce the problem.

Comment 16

[Jonathan Pritchard]

This is so annoying. If you middle-click anywhere on whitespace within a webpage the alert will come up. You don't, to my recollection, have this behaviour on Windows.

Comment 17

[Tethys]

Just FYI, this is the single issue that's preventing me from using a recent version of Firefox as my main browser. I'm behind the times. Fair enough. But I still use FF1.5. And the middle click behaviour is now so ingrained, and I use it so frequently, that I find myself cursing every time I have the misfortune to be using a newer Firefox.

I don't care if you don't make it the default, but please let me have a sane middle click behaviour back. By sane, I mean that pasting into a browser window should have identical behaviour to typing the same content into the location bar. That means using keyword.URL when that content doesn't look like a URL.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 384399 [details] [diff] [review]
don't try to load clipboard content that's not a valid uri

(In reply to comment #8)
> Selecting "keyword param" from somewhere [...] seems like a strange use
> case.

I don't think that's really a strong enough argument to break it, especially since the cost of maintaining it is near-zero.

Comment 19

[Dão Gottwald [:dao]]

Attachment: patch

Uselessness seems like a good enough reason for removing code...

Comment 20

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/4a9b09ae01a7

Comment 21

[Tethys]

Apparently I don't have permission to reopen this bug, but that patch
is clearly not a fix. Yes, I suspect it will remove the error message
(although I haven't tried it), but it won't restore the desired
behaviour, i.e., that which was present in FF up to 1.5, which is
to treat a middle click exactly as if the content had been typed
into the location bar -- i.e., if it looks like a URL, try to go
there, and if not, go to keyword.URL if keyword.enabled is set.

Comment 22

[Dão Gottwald [:dao]]

Disliking a fix isn't a reason to reopen a bug. Please file a new one.

Comment 23

[Dão Gottwald [:dao]]

(In reply to comment #22)
> Disliking a fix isn't a reason to reopen a bug. Please file a new one.

However, that new bug might end up being WONTFIXed. You might want to just install <https://addons.mozilla.org/de/firefox/addon/5531>. I don't think we want to do this by default, as it would cause unintended loads and dataloss.

Comment 24

[Pádraig Brady]

I don't agree this is a separate bug.
It all revolves around what to do when pasting content using the middle mouse.

old: be too lenient and treat everything like a url
new: be too strict and only honor canonical URLs

Now the old case used to hit me occasionally,
but the new case annoys me _many times a day_

So it seems like we should revert to the previous behavior,
or even beter, only discount "URLs" that contain a new line,
which erroneously pasted text usually does.

Comment 25

[Amar Takhar]

For anyone interested I've filed Bug #667340 to have the feature removed by this fix re-introduced.

Comment 26

[Nuno Silva [:njsg]]

(In reply to Pádraig Brady from comment #24)
> I don't agree this is a separate bug.
> It all revolves around what to do when pasting content using the middle
> mouse.

I guess the issue here was that the fix for something involving the favicon ended up changing the whole selection paste behavior.

IMHO it *is* a separate bug because it's unrelated to the issue this bug is about, although it was introduced by the fix for this bug.


> old: be too lenient and treat everything like a url
> new: be too strict and only honor canonical URLs
> 
> Now the old case used to hit me occasionally,
> but the new case annoys me _many times a day_
> 
> So it seems like we should revert to the previous behavior,
> or even beter, only discount "URLs" that contain a new line,
> which erroneously pasted text usually does.

Well, I think the previous behavior was completely expected, I mean, if you try to load something that does not resolve to an URL, you get an error message stating that.

I guess the issue here is this happening over the favicon, either that or people who aren't aware of the feature and misunderstand it (there's nothing confusing about middle-clicking and getting a message about the URL being invalid in a browser that tries to load whatever is in the selection when you middle-click, it's actually pretty obvious it must be the selection text that's not a valid thing to load).

Yeah, getting an alert when middle-clicking is annoying, but either I middle-clicked when I shouldn't, or I was trying to load something that can't be loaded. It's no more annoying than a HTTP 404 message.

Comment 27

[J.O. Aho]

When will this "fix" be reverted?