I can confirm this issue on Windows 10 - not an issue on Mac OS.
A workaround you can use is script the opening/closing of popovers, and then use a visibility flag to display a non-interactive instance of the container field when a popover is open. Or if it works in your context, hide the interactive container field altogether. It's no exactly an elegant workaround, but better than nothing.
TS-Folks will tell me if I'm wrong, but isn't it that a Container with Option 'Interactive content' will be rendered by the Webkit?
If though, WebViewer (webkit) is always predominant and wouldn't allow any overlap into it's area.
Strange if this doesn't occur on Mac OS?!
Love to get more info on which kind of object is predominant over others.
Yes, I was also almost more surprised that the issue didn't occur on Mac OS than that it DID on Windows. Interactive containers are of course "almost" web viewers in many ways. Maybe some OS-native resource for PDFs is being used on the Mac?
Well, first they have to implement a decent layout system, and THEN make a nice documentation on the insights. Can't tell how many bugs there are in the printing layout. I wish I could do everything in HTML...
2 of 2 people found this helpful
Thank you for your post.
This is documented in the FileMaker Pro 15 Help:
Creating and managing layouts and reports > Working with popovers on layouts > Adding a popover
The second bullet point under the Notes section states:
"Windows: Popovers cannot display in front of web viewers or interactive containers in Browse mode. To avoid overlapping these objects, a popover will shrink, if possible, or display behind these objects."
Thank you for the clarification, didn't read that specific part when studying popovers. That said, it's still an inconsistency over Win/OSX, and it should be fixed in my opinion.
Anyway I hope this helps someone who comes from google. I'll fix it by hiding the pdf viewer.