Middle click with url bug in 33.0.0

[Harkonnen]

Palemoon has a feature that when you middle click on the page with url in selection/clipboard it loads that url in current page
In 33.0.0 this behavior is triggered even when focus is in the input field on the web page
I tested that 32.5.2 doesnt do that with input field selected

Pls fix this, and in the meantime, can this whole "middle click with url" feature be disabled somehow?

[Moonchild]

Assuming you're on Linux where this is default behavior...
Set middlemouse.paste to false in about:config

[Harkonnen]

middlemouse.paste to false actually does exact opposite of i want - it disables pasting into input fields, but middle click with urls in selection still loads it in a current page
but this gave me a hint at what options to look, and setting middlemouse.contentLoadURL to false disabled this behavor

[darkarts]

This regression has been biting me as well since the upgrade to 33.0.0. It would be a shame to have to lose the useful paste-url facility because of it. Hopefully it won't be too onerous to fix.

[Moonchild]

Yeah this is a regression from the change in click behaviour. The problem is that Mozilla apparently just completely broke the contentLoadURL behaviour (never navigating) and nobody noticed - our code instead does it too much.

I can fix this, but I need to understand exactly when the middle mouse should not navigate when pasting a URL. Is it only on Input elements? Something else? I'm thinking contentEditable elements might also be a candidate...?

The inherent issue here is that over time people have expected browsers to magically do different things with the same button. Middle click is used for opening links in a new tab, for pasting clipboard contents, for navigating, for opening new tabs/windows, ... you see the issue?

Issue #1957

To be honest I'm thinking of just doing away with this ambiguous "paste a URL on the page content to navigate to it" thing. it's just confusing, ancient, Linux-only behaviour that really could be done just as well by pasting in the address bar. I don't know who introduced this way back when, but it feels like one of those things someone wanted for their personal workflow.

[darkarts]

I can fix this, but I need to understand exactly when the middle mouse should not navigate when pasting a URL. Is it only on Input elements? Something else? I'm thinking contentEditable elements might also be a candidate...?

Good question. It appears to be just on textarea elements that I have noticed the problem so far. Normal (text) input elements such as the search box in the top right corner of this very page currently behave fine.

But in general, I don't expect the browser to try and open what's in the paste buffer as a new URL when middle-clicking:

• on a link

• on a button

• in an input field

• in a textarea

• anywhere outside the rendered page (eg. up in the toolbars)

• in a scrollbar (less important)

The inherent issue here is that over time people have expected browsers to magically do different things with the same button. Middle click is used for opening links in a new tab, for pasting clipboard contents, for navigating, for opening new tabs/windows, ... you see the issue?

Yes, I do indeed. And I use it frequently for opening links in a new tab (and am annoyed when some site-specific javascript intervenes and does something else), pasting text into inputs/passwords/textareas and for navigating. Its use is highly context-sensitive and I understand that this is problematic.

To be honest I'm thinking of just doing away with this ambiguous "paste a URL on the page content to navigate to it" thing. it's just confusing, ancient, Linux-only behaviour that really could be done just as well by pasting in the address bar.

Yeah, but no.

It can be done of course but it's a bit more involved and the real ease-of-use of how it was before this week is why I've never once been tempted to disable it in the options. I would obviously miss it if it were to go and surely am not alone in that. Hopefully it can be retained and the problem with it firing when pasting into textareas can be solved. Thanks.

[distantpluto]

I was having trouble grasping what the problem was until I checked 'middlemouse.contentLoadURL', which I had set to 'false'. Setting it back to true I can see the issue.

This obviously only happens for when the 'primary' (highlight some text and it's available for middle click paste) is a URL and not when the clipboard itself (CTRL+V paste) contains a URL.

Can we not just set 'middlemouse.contentLoadURL' to false as the default? I use the middle click functionality constantly and it would be a massive pain to lose it. How does this setting affect Windows users?

[Moonchild]

Normal (text) input elements such as the search box in the top right corner of this very page currently behave fine.

That's funny because in my testing that's not the case. It would paste the URL and then navigate to it.

But in general, I don't expect the browser to try and open what's in the paste buffer as a new URL when middle-clicking:
on a link
on a button
in an input field
in a textarea
anywhere outside the rendered page (eg. up in the toolbars)
in a scrollbar (less important)

Button, textinput and textarea are all form "input" fields of certain types, so that's easy to address, so is a link (as that is already handled).

Its use is highly context-sensitive and I understand that this is problematic.

Yes it is, because anything can be a link or a JS handler and there is no visual indication what a middle click is going to do on any given element of the page; this is why I'm actually considering removal of this old feature because it's completely ambiguous whether it will work or not, and you may also inadvertently be sending the URL you intended to use for navigation to the webpage you're on (that's a potential privacy issue). It was fine back in the early 2000s to do this but websites have gotten a lot more "interactive" reducing the overall general premise of non-interactive areas where this kind of behavior would work as-expected. There are just too many conditions involved that are "under the hood". It's kind of an "ugly duckling" feature; unexpected unless you are specifically aware it exists.

Can we not just set 'middlemouse.contentLoadURL' to false as the default?

Absolutely. I'll do that for starters. But when it's true and this behavior is still something useful at large I do want to try and make it work somewhat as-expected.

[Moonchild]

I use the middle click functionality constantly and it would be a massive pain to lose it. How does this setting affect Windows users?

It wouldn't affect middle click functionality overall. Please don't misunderstand. It would behave as if middlemouse.contentLoadURL is set to false and otherwise be exactly the way it is already. Only the "if you have a URL in your clipboard and paste it onto the page content in a non-interactive area" would be removed.

It doesn't affect windows out-of-the box since the pref is false on anything but Linux. But if you set it to true and middlemouse.paste to true, it would also affect Windows users. it's just not enabled functionality on Windows out-of-the-box.

[darkarts]

Normal (text) input elements such as the search box in the top right corner of this very page currently behave fine.

That's funny because in my testing that's not the case. It would paste the URL and then navigate to it.

Ah, dammit. You are quite right. I must have stupidly tested with some non-navigable text. Apologies.

Button, textinput and textarea are all form "input" fields of certain types, so that's easy to address, so is a link (as that is already handled).

Sounds good!

[Harkonnen]

If this was broken by a rework of click handling, and fixing this would require rewriting it from scratch, i agree that just nuking entire middlemouse.contentLoadURL is perfectly ok. Its a weird feature, and i am not sure somebody actually uses it, i definitely dont. It was annoying for me even before 33.0.0 (sometimes i accidentally miss the input field when pasting), just not annoying enough to ask how to disable it

[Moonchild]

I'm pretty sure I have an acceptable solution here.
Of course it wasn't as simple as just asking the event what its target was, because layout complexity; but I noticed a pattern I made use of when logging various event objects, so could do a really simple extra check to just "opt-in" only the main content area but not active input elements or similar. So that would mean I can leave the feature in, oddball as it is.

[patrick-g]

Hi,
Linux user here

For the record, I think there is another regression in the middle-click management.
Anything starting with an alpha letter and containing a colon (:) is considered as an URL.
Selecting "kjbmkulkh:ohkjbjkb" (without the double quotes) and clicking middle-mouse button opens an error page with this message:

Code: Select all

The address wasn’t understood
    Palemoon doesn’t know how to open this address, because one of the following protocols (kjbmkulkh) isn’t associated with any program or is not allowed in this context.
    You might need to install other software to open this address.

I can't test with an older version for now, but it seems to me that URL were better recognized before.
I mean that malformed URL were silently ignored.

In my use case (mainly middle-clicking in the scrollbar), setting middlemouse.paste to false do the trick.

[darkarts]

I'm pretty sure I have an acceptable solution here.

If that is the solution which has made it into 33.0.1 then I am pleased to report it works very well for me! Thanks for taking the time to address this.

[Moonchild]

Yes it was uplifted to release 33.0.1
Glad to hear it works well for you.

[digitalaudiorock]

I'm very confused on this one: I just updated from 33.0.0 to 33.0.1 (Linux) and I can't get pasting of URLs to work at all.

What exactly are the about:config settings that should get that to work? Nothing I try is working.

EDIT: OK...I guess I misunderstood the change. I didn't pick up on the fact that pasting URLs into a page and navigating to that URL was removed. Reading the complications with this and all, I get why that was the fix. Can't say I'm too happy with it...been using that forever.

EDIT2: Wow. Now I see why I was so confused: Currently I have both middlemouse.paste and middlemouse.contentLoadURL set to true. Pasting a URL into an existing page DOES navigate. What had me confused is that pasting into a new blank tab does NOT navigate...which did work previously. Was that intentional?

Tom

[digitalaudiorock]

Looking at how this was a total revamp of how this all works, I can see that it depends on allowing this for specific parts of a page...so I get why the old functionality to allow the middle paste in a blank tab no longer works. I just reconfigured stuff so as to not have blank tabs to get around that,

And I actually HAD run into that 33.0.0 issue where pasting into things like text boxes erroneously tried to navigate to URLs. Thanks for that fix!

Tom

[Moonchild]

What did you use as a new tab? A totally blank/empty page might not have a body so it wouldn't work in that case, as it does need content of some sort the way it is now.

[digitalaudiorock]

What did you use as a new tab? A totally blank/empty page might not have a body so it wouldn't work in that case, as it does need content of some sort the way it is now.

Yea, that's exactly what was happening. I had tabs to open as empty tabs. Given the way that needs to be handled now I get why that wouldn't work. I have things set up now so there's always a body there.

Thanks!