search

skyjake / lagrange

A Beautiful Gemini Client
https://gmi.skyjake.fi/lagrange/
BSD 2-Clause "Simplified" License
1.19k stars 62 forks source link

Middle button copy/paste behavior is incompatible with URL field contents being restored after switching focus away #291

Open snan opened 3 years ago

snan commented 3 years ago

Me, just now, deleting an url so I can go select something so I can middle-button-primary-paste it in there, and then switching back to lagrange only to find it's been restored. This happened a couple of times until I ound out what was going on.

ghost commented 3 years ago

For me, this only happens when I've deleted the text in the addressbar before the current page has finished loading.

snan commented 3 years ago

It happens as soon as I shift to another window (which I do in order to select something to paste in).

ghost commented 3 years ago

Ah, ok, I didn't notice that. Yes, it does. So there's two cases it happens in:

skyjake commented 3 years ago

@snan I assume you're on X11? The copy/paste behavior in Lagrange does not conform to the X11 convention of having several different clipboards, one for marked text and one for explicitly copied text. Instead, it only has the latter, which means all platforms behave the same way. (Issue #162) Therefore, deleting the URL prior to doing the middle-button-paste is not needed. It is possible to first make the copy elsewhere and then focus the URL field (left click), and middle-button-paste the URL.

The URL input field in Lagrange is prevented from being empty while the field is unfocused. If you clear it, and then remove focus from the field (with Tab, clicking elsewhere, or by switching to a different app) the current page's URL will be automatically restored.

Let me know if I've misunderstood the use case. I can appreciate this being a negative experience if one expects traditional X11 behavior. This should be addressed at least on X11, and especially after #162 is done.

@krixano That is a related but not exactly the same situation. When a request finishes, the fetched URL is set to the one that was fetched so there no possibility of confusing which URL's content is being shown. An appropriate fix there might be to disable the URL input field while a fetch is ongoing, although then you'd have to manually stop the request before editing the URL via the keyboard, which seems cumbersome.

I'll think about decoupling the URL field a bit more from the current page's URL, but as mentioned they are tightly linked currently to avoid mix-ups.

ghost commented 3 years ago

That is a related but not exactly the same situation.

Yep, I know it's different :) I just wanted to make sure it was mentioned somewhere here on github so you know about it.

snan commented 3 years ago

I can appreciate this being a negative experience if one expects traditional X11 behavior.

Thank you, yes. You've understood the issue correctly.