mainSavannah Administration - Support: sr #110299, minor typo submits unfinished bug...

 
 

sr #110299: minor typo submits unfinished bug report

Submitter:  Dave <barx>
Submitted:  Fri 28 Aug 2020 09:33:14 AM UTC
   
 
Category:  Savannah trackers - bugs, tasks, etc. Priority:  5 - Normal
Severity:  3 - Normal Status:  Works For Me
Privacy:  Public Assigned to:  ineiev
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 11 Jan 2024 07:04:13 PM UTC, comment #10: 

Improved in fae313a.

Ineiev <ineiev>
Site Administrator
Thu 17 Aug 2023 05:36:46 PM UTC, comment #9: 


> > Why impossible?
>
> Because even a manager cannot remove a ticket from the system.  It can only be closed.  But you raise a valid point: my terminology was ambiguous--the typo can be corrected, but it can't be undone, so I should have used the latter term to make that clearer.


Now I don't understand why anything like this should be 'undone'.

> > I just re-submit correctly, noting that the previous one was
> > wrong, and tracker manager closes the erroneous item as duplicate.
>
> The word "just" is doing an awful lot of work in that sentence.  If a single mistyped key requires an explanation from the offending user


Well, the user isn't required to explain anything: tracker managers are intelligent enough to understand such things without explanation.

> and action on the part of a manager, there's a pretty serious design flaw.


Not at all; such items show up quite rarely, and it would be great if the substantial work on the reported issue typically were as little as this.

> This was the point of my search-box example...


I agree this is different.  I disagree it's crucially different.

> Even on my parents' ancient typewriter, where a typo meant breaking out the correction paper, correcting a single mistyped key was less work than this.  I'd like to think a 2020s web site can improve upon the performance of a 1970s typewriter.


I'm sure you are exaggerating.  In 70s, many typewriter users had no access to correction paper at all.

Ineiev <ineiev>
Site Administrator
Thu 17 Aug 2023 11:50:43 AM UTC, comment #8: 

comment #7:

> Why impossible?


Because even a manager cannot remove a ticket from the system.  It can only be closed.  But you raise a valid point: my terminology was ambiguous--the typo can be corrected, but it can't be undone, so I should have used the latter term to make that clearer.

> I just re-submit correctly, noting that the previous one was
> wrong, and tracker manager closes the erroneous item as duplicate.


The word "just" is doing an awful lot of work in that sentence.  If a single mistyped key requires an explanation from the offending user and action on the part of a manager, there's a pretty serious design flaw.  A typo should be immediately remediable by the user who committed it, without littering the ticket system with a malformed entry.

This was the point of my search-box example: prematurely submitting a search request means waiting maybe up to 3 seconds on a particularly slow connection, then fixing the request and resubmitting it.  Typos are extremely common, and fixing them should be quick and easy, not require an explanatory note and management intervention.

Even on my parents' ancient typewriter, where a typo meant breaking out the correction paper, correcting a single mistyped key was less work than this.  I'd like to think a 2020s web site can improve upon the performance of a 1970s typewriter.

Dave <barx>
Thu 17 Aug 2023 09:49:51 AM UTC, comment #7: 

comment #4:

> A single typo should not result in a malformed submission that is impossible to correct.


Why impossible?  I just re-submit correctly, noting that the previous one was wrong, and tracker manager closes the erroneous item as duplicate.

> Do the server logs record what submission method was used?  It would be interesting to see how many used Summary-field submission, and then see how many of those tickets appeared to be inadvertently submitted.


We don't snoop on our users, and in fact, I doubt Apache logs could actually reveal such data.

Ineiev <ineiev>
Site Administrator
Thu 17 Aug 2023 08:16:04 AM UTC, comment #6: 

As an experiment, when adding comment #5, I did not use the mouse to submit it, but hit "Shift-Tab Shift-Tab Shift-Tab Return," and it worked fine.  So there are still keyboard-based submission options that don't involve implicit submission on an unexpected and illogical field.

Dave <barx>
Thu 17 Aug 2023 08:08:52 AM UTC, comment #5: 

Alternately, if you consider Summary-field submission essential to some people's workflow, you could add a simple popup asking for confirmation, defaulting to No, when someone submits via that mechanism.  Then implicit submission changes from the keystroke "Return" to the key sequence "Return, Tab, Return," which is simple to type for those intending it, but exceedingly unlikely to be accidentally typed all in a row.

But given the illogic of the implicit field's placement, I'm skeptical that it's as widely used as you fear.  Do the server logs record what submission method was used?  It would be interesting to see how many used Summary-field submission, and then see how many of those tickets appeared to be inadvertently submitted.

Dave <barx>
Mon 05 Jul 2021 03:06:47 PM UTC, comment #4: 

Another important consideration is how undoable the action is if the wrong key is hit.  If I accidentally hit Enter while typing in a search box, submitting data before I intended, I have only to correct it and try again.  If I accidentally hit Enter on a form that submits a bug report, the incomplete report is submitted and there is no way to undo it (or correct it, in savannah's case, since text fields cannot be edited once submitted).

A single typo should not result in a malformed submission that is impossible to correct.

Dave <barx>
Mon 05 Jul 2021 01:26:34 PM UTC, comment #3: 

Hi Bob, thanks for the reply.

I'm not arguing against there being a keyboard method to submit a bug report.  I'm arguing that the Summary field is a poor place for it.

  • When tabbing through fields in order, the user gets to the Summary before the Original Submission.  How common is it that someone wants to submit a report with a populated Summary and a blank Original Submission?  Granted the former is marked as mandatory and the latter is not, but I bet the cases where the latter is intentionally left blank are exceedingly rare.
  • There is no visible indication on the page that the Summary field is tied to implicit submission.  The behavior is surprising not because users are unfamiliar with implicit submission, but because that's such an illogical place to put it that it ought to be clearly documented if that's where it is.


Implicit submission absolutely makes sense on, say, the front page of a search engine, where there is one text field and the user invariably wants to submit the data after typing it into that field.  I use that behavior all the time.  But on a page with multiple fields the user needs to fill out, it makes little sense to have implicit submission tied to a field in the middle of the page that appears before other fields that will almost certainly need to be populated.

A much more logical and intuitive place for keyboard-based submission is when the user tabs down to the Submit button, which is after all the fields a user might want to populate before submitting.

Dave <barx>
Sun 06 Sep 2020 02:17:06 AM UTC, comment #2: 

Hello,

But on the other side, not having an option for a user to fix their mistake (no matter why they made it) also leads to similar bug reports.

In "majority" of cases we can recognise that the user sends uncompleted form (e.g. empty Original submission field) and let them fix it before final submission.

Anatoly A. Kazantsev <jimcrow>
Thu 03 Sep 2020 05:34:09 AM UTC, comment #1: 

Hello Dave,

I am sorry that you were surprised by this behavior.  However frankly I am surprised that you were surprised by it!  This is the standard behavior of the web since forever.  It has always been this way for literally all of the decades of the web.  I didn't look but I would be surprised if Mosaic was not where this behavior started.  I am surprised you have not noticed this before everywhere.  It is considered important for accessibility.  It is part of the web standard.  Therefore I don't see any way that it could be disabled as a default.  Guaranteed if that behavior were disabled we would very quickly have a hundred people mad at us and a few bug submissions pointing out how we had broken the web.  It's called "implicit submission" for a search term to find more information about it.

Also, this behavior is really a behavior of your web browser on your client side.  Although I do know it is possible to break this behavior using specific HTML or Javascript on the web site side I know that the default is that web browsers are where the Enter is tasked with form submission.  Therefore if you really want to change this behavior then the way to do so is to customize your browser to prevent it.  Maybe you could find a plugin for your web browser that would allow you to disable this?

But in any case consider users with accessibility needs that prevent them from being able to see the pointer position preventing them from using the mouse at all.  Since implicit submission is required in that case it is strongly recommended.  From the HTML5 specification:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission

"There are pages on the Web that are only usable if there is a way to implicitly submit forms, so user agents [browsers] are strongly encouraged to support this."

This is why all web browsers do this by default.  And having been this way forever it is really a default expected behavior.  Changing this would be like changing which side of the road cars drive upon.

Bob Proulx <rwp>
Site Administrator
Fri 28 Aug 2020 09:33:14 AM UTC, original submission:  

Hitting "return" in the Summary field of this bug tracker immediately submits the bug.

Maybe some find this a useful shortcut, but it's undocumented, unexpected, and more likely to be a typo that submits an incomplete item (e.g., http://savannah.gnu.org/bugs/index.php?59030) than a legitimate submission.  At an absolute minimum, a confirmation should be required before the report is submitted; more likely, such carriage returns should be ignored altogether.

Dave <barx>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by jimcrow (Posted a comment)
  • -email is unavailable- added by rwp (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-01-11 ineiev StatusNone Works For Me
        Assigned toNone ineiev
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code