I started to work on this, then noticed @Pastakhov had already claimed the task. I will not step on any toes, but allow me to share what little I came up with:

In mediawiki.js, under permittedHtmlTags I added a new definition set for void HTML tags: voidHtmlTags = { br: true, hr: true, wbr: true }

Then in eatWikiText, line 798, I added:

if ( isCloseTag === true && tagname in voidHtmlTags ) {
	// @todo message
	return 'error';
}

Pretty straightforward. This makes </br>, etc., highlight as red, but it still queues up <br> as if it needed a closing tag. That's where I got stuck. I'm somewhat confident I can figure it out with time, so let me know if you need help.

Another thing... we might need some special handling for <p>. This is valid by itself or with a closing tag. To be precise, the opening tag would have to be followed by flow/palpable content, but the MediaWiki parser will convert plain text into <p> tags anyway, so you shouldn't have to go crazy with validating adjacent content. Instead, just allow people to put <p> by itself, which from my experience is already a common practice in the wiki world.

@MusikAnimal I don't think Pastakhov is working on this. You can safely take it. You approach seems sane.

Change 416628 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/extensions/CodeMirror@master] Highlight void tags and invalid self-closing tags correctly

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

I think this works!

Maybe not.

Okay, ready :)

Wait a minute.
I note that the ticket description says -
a<div />b
Expected: red
Actual: green

That should have been fixed by this patch, right?
FYI, the patch is on commtech wiki for testing.

In T170238#4029129, @Niharika wrote:

Wait a minute.
I note that the ticket description says -
a<div />b
Expected: red
Actual: green

That should have been fixed by this patch, right?
FYI, the patch is on commtech wiki for testing.

I guess I forgot to say that I couldn't figure that one out. It's not the same implementation approach, that's for sure, so I think it may warrant its own ticket.

Another thing... this all seems very fragile. I put some console output to test the flow of execution, and it seems any "state" you set is going to affect everything that follows it, with every keystroke. I'm not saying this is a bad system (performance is quite good, after all), but my point being one could easily fix something and inadvertently break something else. Manually testing for regressions with every change isn't feasible. At quick glance, the code looks unit testable to me, using something like Jasmine (as opposed to acceptance tests, which are a huge, huge pain). This would probably be worth our while if we plan on making more logical changes.

@Niharika It looks like this wasn't merged: https://gerrit.wikimedia.org/r/#/c/416628/ Did you mean to +2 ? :)

Oh whoops. I did mean to +2 it. :)

Change 416628 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Highlight void tags and invalid self-closing tags correctly

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