Page MenuHomePhabricator

[Bug] When typing fast an old parsed value is saved
Closed, ResolvedPublic

Description

When you insert some date, a popup appears while you are typing (I think it's called "ui-inputextender") and builds a meaningful date from the characters you typed. The problem is, this popup reloads as-you-type, and it takes some time to load; so if you press the Save button before the last character of the date was loaded in the popup, then a truncated date is saved (eg. 1 instead of 1999).

I think a safer behaviour would be to disable the Save button when the user types a key and the popup starts loading, and re-enable it when the popup completes.

Event Timeline

Candalua raised the priority of this task from to Needs Triage.
Candalua updated the task description. (Show Details)
Candalua added a project: Wikidata.
Candalua subscribed.

Seems like the behavior is described on T98471, working fast seems to be the problem.

thiemowmde renamed this task from dates sometimes are truncated on saving to [Bug] When typing fast an old parsed value is saved.Sep 15 2015, 2:50 PM
thiemowmde triaged this task as High priority.
thiemowmde set Security to None.

Decisions made in todays story time:

  1. Compare with T98471 and apply the same fix to the date input.
  2. Make a ticket for unifying the relevant JS code.
  3. Find a way to not block the save button. Relevant for power users. It should be possible to hit enter, the missing parsing should be done before saving.
  4. Test delayed/out of sequence responses (see T103086: [Story] Have an "always fail" feature in WikibaseJavaScriptApi for testing purposes).

From what I see this is not related to T98471. The fix applied there is still applied and works for all statements. So, I think this needs investigating from scratch.

I'm not sure if it's a separate issue or not but I'm having a similar problem with it saving (or trying to save) old or incomplete values with monolingual text languages.

For example, I typed "ale" (the start of a language name). It didn't find any results, so I backspaced and typed "mis" instead, added a qualifier and only then tried to save. That gave me an error saying that "ale" is not a valid code, even though that's not what was in the field. I clicked back into the value field so the language popup would reappear, cleared the text in the language field, retyped "mis" and clicked save again. That time it saved it successfully... as Maori (code "mi").

It also saved an old value for an external-id field for me a few days ago, I caught the 4 on the number pad when trying to press enter, deleted it, it still saved the extra 4 - https://www.wikidata.org/w/index.php?title=Q3042964&diff=prev&oldid=333181418 :(

And again and again and again... :(

This time I pasted the URL, double clicked the ID in the URL to select it, pressed ctrl-c ctrl-a ctrl-v and then pressed enter with the same hand (which meant moving it across the keyboard - I couldn't have pressed enter before pressing ctrl-v).

This behaviour looks like the same problem I was encountering (@Sjoerddebruin too) a lot around the same time last year, but it had stopped happening for me for quite a while.

Change 301559 had a related patch set uploaded (by Adrian Heine):
Enable save button after parsing the value

https://gerrit.wikimedia.org/r/301559

Change 301559 merged by jenkins-bot:
Enable save button after parsing the value

https://gerrit.wikimedia.org/r/301559

Jonas moved this task from Review to Done on the Wikidata-Sprint-2016-07-19 board.