Steps to reproduce:

HTML:

<div contenteditable="true" id="edit"><p>test</p></div>
<pre id="output">
</pre>

Javascript:

let output = document.getElementById('output')
let edit = document.getElementById('edit')
let p0 = edit.childNodes[0]

const selection = window.getSelection()
const range = document.createRange()
range.selectNode(p0)
selection.addRange(range)

setTimeout(() => { document.execCommand('insertText', null, 'dummy') }, 1000)
setTimeout(() => { document.execCommand('undo') }, 3000)
setTimeout(() => {
output.innerText = Redo available: ${document.queryCommandEnabled('redo')}
document.execCommand('redo')
}, 5000)

Actual results:

After few seconds we see 'test' and 'Redo available: false'

Expected results:

After few seconds we see 'dummy' and 'Redo available: true' (this is the current behaviour of e.g. Chrome)

Properly formatted Javascript code:

let output = document.getElementById('output')
let edit = document.getElementById('edit')
let p0 = edit.childNodes[0]

const selection = window.getSelection()
const range = document.createRange()
range.selectNode(p0)
selection.addRange(range)

setTimeout(() => { document.execCommand('insertText', null, 'dummy') }, 1000)
setTimeout(() => { document.execCommand('undo') }, 3000)
setTimeout(() => { 
	output.innerText = `Redo available: ${document.queryCommandEnabled('redo')}`
  document.execCommand('redo') 
}, 5000)

After the undo, HTMLEditor does not compute active editing host. Then, redo fails. Thus, this is related to bug 413687.