Expected results: a warning
Actual results: the new comment is saved with only a quotation.
Ive done this a few times when on a small mobile using chrome. Fat fingers, and the page jumps around a bit while loading causing me press a button that unexpectedly appeared under my thumb.
Basically I think this occurs very rarely, is immediately recoverable (via edit or follow up comment). We also have plenty of valid reasons someone wants to post just a quote (especially on long threads). I can't see much value in spending engineering time on this, personally.
I would generally assume most people quote without text intentionally, more so than accidentally. At least anecdotally I quote things without comment and I don't recall doing it by accident. If it something with page loads, we could maybe take a look into that specifically.
(via edit or follow up comment). We also have plenty of valid reasons
someone wants to post just a quote (especially on long threads). I can't
see much value in spending engineering time on this, personally.
I am not entirely surprised by the current behaviour, so I suppose this is
a feature rather than a bug.
If some needs to repost an old comment without any input of their own, that
feels like a hack around some missing functionality.
O well. I guess I can reply via email instead when on mobile.
Quoting and signature stripping works properly in major clients -- you can find the implementation here:
...and a bunch of test coverage here:
It looks like your client sent us raw text with no reply/quote markers. If you want to file a separate issue about this (particularly, include which client you're using and how you have it configured) we can see about resolving it.
The original behavior is expected and intentional. It directly reflects our best guess at user intent, and we haven't seen other reports of this issue.
If there's some other root issue, like editing/submitting forms being difficult to interact with on mobile, or the "Quote + Edit" interaction somehow being difficult, feel free to file a new report in that vein and describe what sort of input error you're making. We're more likely to look at making changes there (i.e., prevent you from making the mistake in the first place, no matter what you're doing) than to look at making this particular change to catch a narrow case of the mistake.
Examples of changes we might look at in response to input errors are changing the size / position of inputs, changing the focus/scroll behavior after selecting "quote text", trying to smooth out the scrolling, disabling the submit button for a moment after a scroll or quote, etc. But this report doesn't have enough information about how these edit errors are occurring to allow us to think about solutions to the problem. I haven't experienced difficulty with inputs myself, and I don't recall reports from other users. The issues you're seeing may be particular to your device.
I used gmail app. I was using inline quoting, hoping to have a result similar to the web "quote" function.
The tests you mention don't include any inline quotation, and a little browsing Maniphest leads me to T5181: Parse in-line replies in email responses .
I'll keep an eye out for any pattern in Phab's web UI misbehaving on that device of mine.
But as a general solution, not just for my specific mobile problem, I like your suggestion to disable the submit button until after the UI is fully loaded and stable after the cursor has been re-positioned to the textbox. That is an increasingly common approach for web UI buttons.
Regarding this bug report, it isnt enough to consider what the user intent was, but also the impact it has on other users. IMO any comment that just quotes an existing comment from the same maniphest task has a very low signal:noise ratio for other people who are subscribing to it.
The requested confirmation dialog is a common feature of many similar tools, and many email clients.
Even on Differential this type of behaviour can be seen, as it is not possible to save an empty Draft comment. When the user click "Save Draft" on any empty comment, the UI delightfully disregards the user intention, discarding the comment instead of saving it.
The difference between reply on Differential and Maniphest is that on Maniphest the context is part of the reply edit box, so the simplest implementation is to allow submitting a "context only" reply.
It shouldnt be too much to ask them to justify that noise by adding a short note to the quotation, so it isnt a "context only" reply, or confirming that they are sure they want to send a "context only" response.
No doubt you will get bug reports from people who believe they should be able to send out empty-ish "context only" responses, without needing to respond to a confirmation dialog, but then you can work with them to build use cases for their needs and probably build more optimal solutions.