I'm happy to pick this up if you're good with PRs. Some quick code diving makes it seem like the problem is probably here; I'm suspicious that when we dispatch this event back to obsidian it doesn't end up going to the right place (or getting through at all) in the context of a table.

PRs are more than welcome. I haven't had a chance to dig into this yet, but I suspect you're right about the cause. CounterWidget likely has the same problem.

Some actual debugging with console logs suggests that when the inline text is in a table, we render the Clock from here rather than using ClockWidget at all. Trying to understand a little better; given that we have the inline plugin, what is the code in handleMarkdownPostProcessor trying to accomplish? Is that supposed to be doing something for the non inline clocks?

Oh, interesting. handleMarkdownPostProcessor is what's used when you're in View mode rather than Edit mode; it looks like in table cells, Obsidian is using handleMarkdownPostProcessor to render cell contents (even when it's in edit mode), rather than the widgets it normally uses in edit mode.

The Clock object in handleMarkdownPostProcessor will still emit the update event, the problem will be getting a handle to the editable source for it. The widget gives you the built in nodeFrom and nodeTo; I don't know if there's a way to get that context information from handleMarkdownPostProcessor.

Draft PR here but still having some issues. More to discuss on the PR thread.