Page MenuHomePhabricator

Frustrating delay between entering a value for a statement and being able to save
Closed, DeclinedPublic13 Estimated Story Points

Description

Problem:
There is a delay between entering values when adding/editing statements and being able to save the changes. This is particularly frustrating for people who are used to pressing enter to save, because they have to either wait for the interface to react before pressing enter, or hammer the enter key until it works. This also makes the interface seem slow, laggy and unresponsive.

Steps to reproduce:

  • Copy some text to the clipboard, e.g. the word "test"
  • Go to an Item, e.g. Wikidata Sandbox
  • Click "add statement"
  • Select a string property, e.g. Sandbox-String, and make sure the value field is focused
  • Press the appropriate keyboard shortcut to paste (e.g. ctrl-V) immediately followed by the enter key to submit the edit

Expected outcome: The saving process begins (which will either be successful and then exit editing mode, or encounter an error, display an error message and return to editing mode).
Actual outcome: Nothing happens, as if the enter key had not been pressed.

Pickup notes

Agreed while picking this up to investigate, write up options, and do any low hanging fruit in this area

Acceptance criteria:

  • We know what can be done to tackle this issue
  • Delay between entering a value (of any type) and being able to press enter is reduced (using any low hanging fruit available)

Event Timeline

For string properties specifically, this could have gotten worse recently-ish due to T261071: Malformed input error on text which is not malformed: we now send the string to the server for parsing/validation.

I guess we could try to enable the “publish” button earlier, and then saving would just take longer (because it would now wait for that parse API request to complete), but that doesn’t sound like a good idea for all datatypes: e.g. for item-type properties, I don’t think we want to let users enter an arbitrary string, press Enter immediately, and just hope that the right item will be selected…

Enabling the publish button sooner would help a lot – if it takes a bit longer to save, that's perfectly fine.

I guess we could try to enable the “publish” button earlier, and then saving would just take longer (because it would now wait for that parse API request to complete), but that doesn’t sound like a good idea for all datatypes: e.g. for item-type properties, I don’t think we want to let users enter an arbitrary string, press Enter immediately, and just hope that the right item will be selected…

For me this is most notable exactly for item-type properties, where the delay between choosing the item you want from the dropdown list (because you always have to explicitly choose one) and the publish button being enabled feels very long. And since you have to explicitly choose one, i don't think "keyboard smashing" + Enter would be a big issue?

I guess we could try to enable the “publish” button earlier, and then saving would just take longer (because it would now wait for that parse API request to complete), but that doesn’t sound like a good idea for all datatypes: e.g. for item-type properties, I don’t think we want to let users enter an arbitrary string, press Enter immediately, and just hope that the right item will be selected…

For me this is most notable exactly for item-type properties, where the delay between choosing the item you want from the dropdown list (because you always have to explicitly choose one) and the publish button being enabled feels very long. And since you have to explicitly choose one, i don't think "keyboard smashing" + Enter would be a big issue?

Hm, indeed there’s one more wbparsevalue and two wbformatvalue requests after selecting an item from the dropdown. That does seem superfluous :/

Addshore renamed this task from Frustrating delay between entering a value for a statement and being able to save to Frustrating delay between entering a value for a statement and being able to save [Timeb.Jun 18 2021, 9:41 AM
Addshore updated the task description. (Show Details)
Addshore set the point value for this task to 13.
Addshore updated the task description. (Show Details)
Lucas_Werkmeister_WMDE renamed this task from Frustrating delay between entering a value for a statement and being able to save [Timeb to Frustrating delay between entering a value for a statement and being able to save.Jun 18 2021, 9:42 AM

One initial maybe unrelated finding.

We seem to ship a deprecation warning with every response from the frontend to wbparsevalue. Not sure if this would have any noticeable impact but seems like a waste of text when we are the owner of the frontend + backend.

{
  "warnings": [
    {
      "code": "deprecation",
      "data": {
        "feature": "action=wbparsevalue&parser"
      },
      "module": "wbparsevalue",
      "*": "The parameter \"parser\" has been deprecated."
    },
    {
      "code": "deprecation-help",
      "module": "main",
      "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes. Use [[Special:ApiFeatureUsage]] to see usage of deprecated features by your application."
    }
  ],
  "results": [
    {
      "raw": "Assignment of the gene (EPLG2) encoding a high-affinity binding protein for the receptor tyrosine kinase elk to a 200-kilobasepair region in human chromosome Xq12.asd",
      "value": {
        "text": "Assignment of the gene (EPLG2) encoding a high-affinity binding protein for the receptor tyrosine kinase elk to a 200-kilobasepair region in human chromosome Xq12.asd",
        "language": "en"
      },
      "type": "monolingualtext"
    }
  ]
}

One initial maybe unrelated finding.

We seem to ship a deprecation warning with every response from the frontend to wbparsevalue. Not sure if this would have any noticeable impact but seems like a waste of text when we are the owner of the frontend + backend.

T233293: wikibase/javascript-api (wikibase-api) should use datatype instead of deprecated parameter parser

One initial maybe unrelated finding.

We seem to ship a deprecation warning with every response from the frontend to wbparsevalue. Not sure if this would have any noticeable impact but seems like a waste of text when we are the owner of the frontend + backend.

T233293: wikibase/javascript-api (wikibase-api) should use datatype instead of deprecated parameter parser

Oh interesting

The general behavior seems to be what @Lucas_Werkmeister_WMDE described earlier.

  1. wbparsevalue happens
  2. wbformatvalue happens for html representation and triggers drawContent() which in turn triggers 3
  3. wbformatvalue happens again for text representation

Possible changes that I could come to think of.

  • wbparsevalue returns most of the data required to construct 2 and 3 but isn't currently able to do any formatting. One possible solution could maybe be to have all of these in a single call, however that sounds like a massive change.
  • Always include the text representation from wbformatvalue as the data for this most likely will be available when creating the html representation. The third request seems like an unnecessary rountrip and will always be called. This could be done quite easily I think but might add additional (unanted) overhead to other things that is using wbformatvalue, maybe with an optional flag this could be included.

However none of those suggestions would guarantee to solve the paste issue, for that we would probably need to do everything in one request or keep track of the enter button being pressed in succession after the wbformatvalue was called.

We could change wbformatvalue to take multiple formats at once. We’d keep the generate parameter, at least for now, with the same result format, for compatibility, but add another one (e.g. formats) that takes multiple formats, and then the result would become a mapping from format to formatted value, or something like that.

One question with this approach would be whether the options parameter can be left as is or whether people will want to pass different options to the different formatters. (It’s not very clear what this parameter is used for at all – see T256407 and T260553.)

Though I think a wbparseandformatvalue module would also be an acceptable option (especially if we mark it as internal), to do everything we need in one request.

Though I think a wbparseandformatvalue module would also be an acceptable option (especially if we mark it as internal), to do everything we need in one request.

I think a wbparseandformatvalue, might be the most desired approach for me. That way we could get it down to just one request, and by the looks of it on the javascript side we would have to do most of the changes in jquery.valueview.valueview.js.

For string properties specifically, this could have gotten worse recently-ish due to T261071: Malformed input error on text which is not malformed: we now send the string to the server for parsing/validation.

I guess we could try to enable the “publish” button earlier, and then saving would just take longer (because it would now wait for that parse API request to complete), but that doesn’t sound like a good idea for all datatypes: e.g. for item-type properties, I don’t think we want to let users enter an arbitrary string, press Enter immediately, and just hope that the right item will be selected…

Would that actually happen? I wouldn't expect it to select a search result for you. I would expect it to only continue with the save if the value you've told it to save is a valid value for the property. "some text" would not be a valid value for an item property because it's not an item ID, so I would expect that to fail, whereas "Q123" is an item ID and could be saved (assuming the item exists).

Change 701359 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/Wikibase@master] [WIP] Introduce wbparseandformatvalue

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

I'm really sorry to say this but we decided not to fix this issue. It is a very valid issue and we understand the frustration but on the other hand the code behind this is extremely old and problematic making this problem extremely hard to fix. Introducing an API endpoint to handle most of the work is easy and a patch for it is already up but the frontend code that would use this endpoint is impossible to write without major changes to the code that would take weeks of developer time to implement.

This will be automatically tackled once we start rewriting the old frontend code (based on jquery.ui) to something more modern (VueJS and using design system) and the developer time should focus on getting there sooner.

Change 701359 abandoned by Ladsgroup:

[mediawiki/extensions/Wikibase@master] [WIP] Introduce wbparseandformatvalue

Reason:

not planning to work on it, if anyone is willing to, feel free to restore and take over.

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