Is there a known workaround for fixed elements rendering in the wrong place when the iOS virtual keyboard is on screen?

I've got an app which leverages a WKWebView for most of the content. In a few screens we have buttons in a div which leverages position: fixed; so that they're always in the same place as a long form scrolls underneath. When the virtual keyboard is shown I add a class to the document body that can be used to adjust other things, for example, tweaking the bottom property on the div containing these buttons so they move above the keyboard.
So far, so good, they're always visible. The problem arises when the form is then scrolled, the buttons visibly move up with the rest of the page (which they shouldn't), but the browser actually acts as if they're still position where they're supposed to be. The screen shot shows where the browser believes the buttons are, and if you touch those areas then the buttons get activated.

I'm happy to chalk this up as a bug with WebKit or specifically WKWebView, but is there a known workaround for this so that they render in the correct place? I read that adding a translation to trigger hardware rendering could help, but it doesn't seem to have done the job here. I also read that changing the position to absolute could solve this issue, but for me it just results in them being rendered off screen somewhere altogether.


from Is there a known workaround for fixed elements rendering in the wrong place when the iOS virtual keyboard is on screen?