Stuck in waiting state when trying to validation record via URL

[twagoo]

When submitting the URL of a CMDI instance at https://curation.clarin.eu/ (Curation Dashboard 6.3.1), the submit button appears to remain stuck in the "Validating" state (endless spinner).

I have tested this with various URLs

• https://lindat.mff.cuni.cz/repository/oai/cite?metadataPrefix=cmdi&handle=11234/1-4804
• https://vlo.clarin.eu/data/clarin/results/cmdi/The_Language_Archive/oai_www_mpi_nl_tla_1839_00_0000_0000_0015_9D0C_F.xml
• https://europeana-oai.clarin.eu/metadata/harvester-output/europeana/results/cmdi/Europeana/0003/http_data_europeana_eu_item_221_URN_NBN_SI_DOC_3YY3QMRZ.xml

Note that I have not been able to observe a hard timeout or any issues in the console. The validation just appears to take infinitely long without any explicit errors.

[wowasa]

I just tried it for the three URLs and I got a result for each:

[wowasa]

my assumption is that it takes too long to load the concepts from concept registry when the cache is empty. This would explain why I've got a result and you haven't. Hence we need to persist the cache in some way between restarts of the web-app (for the app it isn't crucial, since we don't risk time-outs there).

I'm going to create a new issue with the specific task

[twagoo]

Interesting, for me the submit form still gets "stuck" when I try again for these URLs. Also, downloading the record and then submitting it via the upload functionality yields a report within seconds. Both in Firefox and Chrome on MacOS.

[wowasa]

ok - cache would not explain the different behavior between URL and file upload

[twagoo]

I played a bit around with the Javascript, and I found that there are two events bound to the 'validate' button, one of which seem to prevent the form from being submitted. If I disable that event using the developer tools of Firefox, or turn off Javascript altogether, the form submits as expected even though no spinner is shown. So that hopefully narrows it down quite a bit.

It is the second event in the screenshot below, I don't know exactly how it is bound to the button.

[wowasa]

at least I can reproduce the issue in Chrome, while everything is fine in Firefox 115.8.0esr

[twagoo]

at least I can reproduce the issue in Chrome, while everything is fine in Firefox 115.8.0esr

I'm on Firefox 123.0 if that's of any help

[wowasa]

a very nice issue which took me some hours to resolve and reminded me my dislike of javascript...

In fact the cause of the issue is in the following lines of code in curation.js: $('#validateButton').click(function() { //only change to spinner if input is valid if($('#url-input').val()){ $(this).html('<div>Validating...&nbsp;&nbsp;&nbsp;&nbsp;</div><div id="uploadWheel" class="spinner"></div>'); $(this).prop('disabled', true); } });

We either place div inside a button element or replace the button element by div elements and try to disable the button element then. Both doesn't make sense and browsers more recent than in my Debian seem not to tolerate it.

Instead of the html method I'm adding a hidden div container with the spinner to the html file and activate either the button or the spinner by javascript

[wowasa]

resolved for v. 6.3.2