Open question for the engineers:
If I'm not mistaken, steps 1. and 2. (from above) are already happening when a user initiates an OCR process?

No, in the MVP T280848 only step 1 is done, the disabling (it actually also disables the button; is that bad?).

Also, I'm not sure what the behaviour is supposed to be when a user clicks Extract text but there's already text in the editing box. It looks like that text should be removed first so the loading message can be seen. Or as the disabling increases the opacity of any existing text (or does it just make it grey? anyway…) the loading message can be put on top, with whatever styling it needs (i.e. a more solid background colour).

Thanks @Samwilson!
There should be a warning message to let the user know that the task they're performing will replace the current text they have (especially if they have already started doing edits to the text). T281767 has the visual of the popup that should appear before the user continues and then the editing box is greyed out and the loading message appears on top of the box.

@Samwilson here is the updated UI for loading state:

• No text in the page body field

• Existing text in the page body field

Change 697912 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/Wikisource@master] Add loading indicator while OCR is running

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

Change 697912 merged by jenkins-bot:

[mediawiki/extensions/Wikisource@master] Add loading indicator while OCR is running

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

1. the page body text field is disabled

Yep.

1. a loading icon along with "OCR in progress..." appears on the top left corner of the page body text field

Yes, but see T284971#7162820.

1. a "Cancel" button is added next to the "OCR in progress..." status, in case the user wants to terminate the OCR process early.

If you press cancel, the OCR process will continue in the background, but any OCR text that is returned will be ignored (i.e. the text field will be unchanged). As far as the user is concerned, nothing will have happened.

If the OCR process returns an error, this will be displayed (as per T281767#7162945).

While testing this I came across a bug where Enter and the arrow keys stopped working in the text field. Because this bug also affected other text input on the page (e.g. Search, Summary) and I have found reports of similar bugs affecting Firefox in other place, I am assuming it is just a Firefox bug. But, I will keep an eye out for it.

Test environment https://en.wikisource.beta.wmflabs.org Wikisource – (cb4c670) 06:21, 18 June 2021.
Test browser: Firefox 78, Chromium 87

Change 700831 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/Wikisource@master] Don't emit textExtracted event if OCR has been cancelled

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

Thanks for pointing out the error-when-cancelled state, @dom_walden. The above patch fixes this.

Change 700831 merged by jenkins-bot:

[mediawiki/extensions/Wikisource@master] Don't emit textExtracted event if OCR has been cancelled

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

Question re:

While testing this I came across a bug where Enter and the arrow keys stopped working in the text field. Because this bug also affected other text input on the page (e.g. Search, Summary) and I have found reports of similar bugs affecting Firefox in other place, I am assuming it is just a Firefox bug. But, I will keep an eye out for it.

What happens to a bug like that when you encounter it @dom_walden do we add it to our next sprint? where does it go?

In T282050#7173514, @NRodriguez wrote:

Question re:

While testing this I came across a bug where Enter and the arrow keys stopped working in the text field. Because this bug also affected other text input on the page (e.g. Search, Summary) and I have found reports of similar bugs affecting Firefox in other place, I am assuming it is just a Firefox bug. But, I will keep an eye out for it.

What happens to a bug like that when you encounter it @dom_walden do we add it to our next sprint? where does it go?

Oh, it does not seem to be a bug we have caused or can fix. It seems like a bug in the Firefox code. Sorry if that wasn't very clear.