It looks like the advertising popups can capture the keyboard inputs. I see it most often when editing an earlier post.
You can easily click back in t<LOST INPUT>he window but it sure is awkward. I also notice <LOST INPUT> the popup has a new provide<LOST INPUT>r, 'Ads By GumGum'.
So I just enabled all "Ad Blocker" extensions in Safari and added this p<LOST INPUT>ost. So whatever this popup is doing bypas<LOST INPUT>ses the Safari "Ad Blocker."
So I switched to Firefox to see if it is browser specific. To test, I need to type in at least as much as I've already type in the previous paragraphs. Good news, Firefox did not have a keyboard capture event. Sure sounds like an anti-Apple 'feature.' Now to have some fun.
So let's see if we can overflow a buff<LOST INPUT HELD KEY> no effect. Now for p<LOST INPUT>hase two.
I'm trying different /etc/hosts entr<LOST INPUT>ies. For the next trick, we'll block "gum.criteo.com". So far, so good! If this kills the keyboard hijacking, problem solved. I still see the po<LOST INPUT>p-ups. Now for the 3d test. It does appear the keyboard hijack occurs whe<LOST INPUT>n the popup shows up. Now the forth domain is blocked. <LOST INPUT>Sure enough the popup is concurrent with the lost keyboard.
Now testing "Disable Javascript" which changes the edit window and background screen. No popups, no problem with keyboard hijacking. It looks like we're narrowing in on the problem area. This suggests I need to audit a failing (or hostile) Java Script.
I've backed out the last /etc/hosts entry since it had no effect. But I continue to disable various Safari browser options. So far, I still see popups but not the keyboard hijacking one and its effect. This is good news!
Just sharing including my debug session. This last debug test appears to make Safari working with InsideEvs without the keyboard hijacking. There may be other problems at other web sites but for now InSideEVs is working.
Bob<LOST INPUT> Wilson