Naming strategy not applied if the user submits the page creation form too fast

On the page creation form (the /create action), requests to /get/XXX/?xpage=entitynamevalidation_json&outputSyntax=plain&name=NNN&form_token=TTTT  are made as the user types the page title. The targetName field is disabled and then reenabled when the request succeeds.

If the user submits the form (by clicking on create or pressing enter in the name field), the field remains disabled, a red notification "toast" with the entitynamevalidation.nametransformation.error message is briefly displayed ("Error while transforming the page title to a correct page name: the exact page title will be used."), and the form is submitted.

An aggravating factor is that the last request (with the final page name) is done twice: once after the user is done typing, and once after the user focuses out the field by clicking on the button.

All this happens in the xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-war/src/main/webapp/resources/uicomponents/widgets/locationPicker.js file.

As a result, the page is going to be created without following the naming strategy. If the user happens to have typed a title that does not match the strategy, they will be sent back to the page creation form with the following confusing error message "Cannot create document [...] because its name does not respect the name strategy of the wiki. Change the name or move the parent to another space."

Reproducing this issue can be tricky on a fast internet connection if the server answers quickly. A slow internet connection can be simulated with from the network tab of the browser web developer tools.

To fix this issue, I suggest:

• Avoiding this duplicate request happening when focusing out of the page title field. This is possible by saving the last result and use this instead of doing a request if the page name hasn't changed in the meantime. This will save a request, saving bandwidth usage and server computation
• blocking the form submission until the request succeeds

I'm attaching WorkaroundNamingStrategy.xml, which is a document that implements a workaround for this bug. This workaround implements this second item.

Note that the /createcr/ action of the Change Request Application (CRAPP) is also affected (with the Request for Creation button).