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.
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.
See also bug 254714 about setting the address before the URL starts loading.
Component: Location Bar and Autocomplete → General
QA Contact: location.bar → general
Summary: Middle-click on Site Icon makes confusing alert → Middle-click on favicon or content area produces confusing alert if there's no valid url in the clipboard
Created attachment 384395 [details] [diff] [review] fixup urls
Assignee: nobody → dao
Status: NEW → ASSIGNED
Created attachment 384399 [details] [diff] [review] 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.
Attachment #384399 - Flags: review?(gavin.sharp)
(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?
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.
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 .
(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
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.
Fixed in Firefox 3.5.1~!
This hasn't changed in Firefox 3.5.1.
Well a fix that was released must have fixed it. After I upgraded, I can not reproduce the problem.
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.
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 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.
Attachment #384399 - Flags: review?(gavin.sharp) → review-
Created attachment 440577 [details] [diff] [review] patch Uselessness seems like a good enough reason for removing code...
Attachment #440577 - Flags: review?(gavin.sharp) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a5
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.
Disliking a fix isn't a reason to reopen a bug. Please file a new one.
(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.
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.
For anyone interested I've filed Bug #667340 to have the feature removed by this fix re-introduced.
(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.
When will this "fix" be reverted?
You need to log in before you can comment on or make changes to this bug.