GNOME Bugzilla – Bug 756955
Text is not pasted in entry text box if users cancels the upload to paste service dialog
Last modified: 2021-06-10 11:03:34 UTC
When we paste text, polari asks to upload to paste service, on clicking on cancel, the text is not pasted to the text box. In commit 362990fee0f5ac (entryArea: Don't flash pasted text when using paste service) we stopped pasting text on text box, but need to handle the case when user cancels.
Created attachment 313855 [details] [review] entryArea: Handle case if user cancels upload to paste service dialog
(In reply to Kunaal Jain from comment #0) > When we paste text, polari asks to upload to paste service, on clicking on > cancel, the text is not pasted to the text box. That was actually intentional - pasting more than a couple of lines without using a paste service is generally considered rude (see some reasoning in https://bugzilla.gnome.org/show_bug.cgi?id=756681#c1), so I still don't think we should allow it. Also note that the commit you referenced has nothing to do with that behavior - we did paste the text to the entry before, but both paste and cancel buttons cleared the text.
(In reply to Florian Müllner from comment #2) > (In reply to Kunaal Jain from comment #0) > > When we paste text, polari asks to upload to paste service, on clicking on > > cancel, the text is not pasted to the text box. > > That was actually intentional - pasting more than a couple of lines without > using a paste service is generally considered rude (see some reasoning in > https://bugzilla.gnome.org/show_bug.cgi?id=756681#c1), so I still don't > think we should allow it. As Bastian said, lets take your word for it. But my thoughts, although long messages are frowned upon, we as IRC Client shouldn't be the one restricting. There are sometimes, when I just want to paste a 5-6 line thing, and I'd prefer if this appears in conversation, rather than as a paste service link. Also we are by default asking user to post it to paste service, he is explicitly clicked on cancel, so he should be able to send the text as normal message. Presently there is no way he can send a long message, even in exceptional situations. > Also note that the commit you referenced has nothing to do with that > behavior - we did paste the text to the entry before, but both paste and > cancel buttons cleared the text. Yes, I meant earlier we pasted text, so I was justifying the use of this line `this._entry.text = this._pasteButton.action_target.deep_unpack()`. Otherwise not doing anything would have done the trick.
(In reply to Kunaal Jain from comment #3) > But my thoughts, although long messages are frowned upon, we as IRC Client > shouldn't be the one restricting. There are sometimes, when I just want to > paste a 5-6 line thing, and I'd prefer if this appears in conversation, > rather than as a paste service link. Sure, pasting 5-6 lines inline is fine - I'm certainly open to bump up the limit a bit. But pasting 10, 20 or more lines is only OK when the server doesn't throttle flooding, and we don't know how a server is configured; however this should really only be the case for internal or very obscure servers. We may end up adding a connection option to turn off the paste service, which would allow users to turn it off where it is not needed (or when they hate it so much that they'd rather violate netiquette than use it). I do think this is a better option than asking the user each time she pastes multiple lines. > he is explicitly clicked on cancel, so he should be able to send the text > as normal message. I disagree. And if we wanted this, the UI would be wrong - instead of letting the user cancel the message and then send it, the Cancel button should be changed to something like "Send inline" or so.
(In reply to Florian Müllner from comment #4) > Sure, pasting 5-6 lines inline is fine - I'm certainly open to bump up the > limit a bit. But pasting 10, 20 or more lines is only OK when the server > doesn't throttle flooding, and we don't know how a server is configured; > however this should really only be the case for internal or very obscure > servers. > > We may end up adding a connection option to turn off the paste service, > which would allow users to turn it off where it is not needed (or when they > hate it so much that they'd rather violate netiquette than use it). I do > think this is a better option than asking the user each time she pastes > multiple lines. > > > > he is explicitly clicked on cancel, so he should be able to send the text > > as normal message. > > I disagree. And if we wanted this, the UI would be wrong - instead of > letting the user cancel the message and then send it, the Cancel button > should be changed to something like "Send inline" or so. I agree with your points, but what we are doing currently is problematic IMHO. I can think of two options.. 1.) From 5 to 10 lines, have option of Paste as inline or paste service, beyond that it is cancel or paste service. 2.) Just add an option in connection dialog to disable paste service, in that case we will use normal inline paste. Perhaps we can add this option in new UI, as being discussed on bug 756344, or I can add a toggle in present UI too.
(In reply to Florian Müllner from comment #2) > (In reply to Kunaal Jain from comment #0) > > When we paste text, polari asks to upload to paste service, on clicking on > > cancel, the text is not pasted to the text box. > > That was actually intentional - pasting more than a couple of lines without > using a paste service is generally considered rude But what about those specific circumstances in which it isn't considered rude? Shouldn't be there a way to actually paste it? Increasing the limit to 15-20 lines and adding an option to disable it would be improvements over the current situation, but I'm a bit concerned about software guessing what could be rude in a given situation and preventing it from happening at all.
In general I agree with Florian on this one. I would really like to be able to post shorter multi-line messages though (of around 5-6 lines). This would make composing lengthier posts a lot easier. Maybe allow adding new lines with Shift+Return, and grow the input field vertically to show the entire message?
The reason for the message and blocking of inline pasting should be explained, either inline or with a link to a help page - it's not necessarily clear to someone unfamiliar with multi-line issues what a paste service is or why inline pasting is being blocked. For example: "Pasting many lines on IRC is likely to cause problems. (_more info_) [Cancel paste] [Send to a public paste service]" The more info link could then explain problems re. e.g. throttling/blocking/interspersal, and detail how to disable the limit for specific servers if that option is implemented. Also, with fewer than 5 lines at the moment, a hex box is displayed in place of newlines in the inline paste (though I guess that's a separate bug :))
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Polari, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/polari/-/issues/ Thank you for your understanding and your help.