For issue 1, my logic here is that blocked links are (probably) going to be a very uncommon case, so it's better to not have a mandatory second-ish pause every time you edit a link, and the case where someone misses noticing it because they're acting quickly is the same reject-on-save behavior we've been happy enough with for years. That said, perhaps a sensible fallback would be to hook it into the context for the link, since that'll still be showing once you leave the inspector...

For issue 2, interesting that the submit-on-enter behavior isn't checking whether the action is disabled. I'll look into whether that's widespread, or whether I'm disabling the action in the wrong way somehow.

2. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

Change #1048831 had a related patch set uploaded (by Esanders; author: Esanders):

[oojs/ui@master] Dialog: Check if an action is disabled in the UI before executing

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

(executeAction is called directly quite rarely, so I doubt we would have a problem with the above breaking change: https://codesearch.wmcloud.org/search/?q=executeAction%5C%28&files=&excludeFiles=&repos=#Extension:VisualEditor)

Change #1048831 merged by jenkins-bot:

[oojs/ui@master] Dialog: Check if an action is disabled in the UI before executing

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

In T368179#9914803, @DLynch wrote:

For issue 1, my logic here is that blocked links are (probably) going to be a very uncommon case, so it's better to not have a mandatory second-ish pause every time you edit a link, and the case where someone misses noticing it because they're acting quickly is the same reject-on-save behavior we've been happy enough with for years. That said, perhaps a sensible fallback would be to hook it into the context for the link, since that'll still be showing once you leave the inspector...

Yeah, on second thought, you're right. And I agree it'd be nice to show it in the context too. That would also help in the case when an external link is pasted directly into the editing surface.

In T368179#9914958, @Esanders wrote:

2. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

There is at least one place in VE where we actually allowed executing an action while its button is disabled, and it's in the same inspector:

In T214453#4907940, @matmarex wrote:

After the patch, there remains one case where "Enter" will have an effect while the "Done" button is disabled: if the textfield is empty, pressing Enter will remove the link. This is intentional.

Maybe it's okay to change it though. It fails in a weird way with this OOUI patch:

In T368179#9914958, @Esanders wrote:

2. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

It would technically be a breaking change

(Well it was one, Convenient-Discussions's screenshot upload functionality built upon mw.Upload.Dialog executes the save action right after upload action if all input fields are autofilled. The primary action stays disabled so that the user doesn't decide an action is required from them.)