Eventually when we add web extension support we might have situations where multiple remote browsers are embedded in the same layer tree each of which host a set of windowed plugins. CompositorParent's UpdatePluginWindowState currently assumes that it will be called once during composition. In this call it accumulates a list of visible plugin windows associated with the remote layer tree it happens to be processing. That list is then sent over to CompositorChild which applies the updates to visible windows and hides all other plugin windows that the browser window manages. If we have two remote layer trees, both with plugins, we'll send two plugin window lists during composition and the second update will overriding the first. To fix this we'll need to accumulate windowed plugin updates in a master list on the parent side and flush that to the child after the walking the layer tree is completed. This way the accumulated plugin data contains all visible plugins associated with all the remote layer trees.
Not actually sure if this blocks bug 1190679 or not. The remote browsers we create for WebExtensions may all be separate OS windows, so we would have different layer trees. I'm not sure though.
So... what does this mean?
Nothing. Please ignore for now. Just tracking some platform work that may need to happen eventually.
The one WebExtension case I can think of that's not in a different window is sidebars. So this is only an issue if we run WebExtensions OOP and we implement sidebars.
We've implemented sidebars, but I think you did it without plugin support. So just wanted to confirm this wasn't going to be an issue.
No, I forgot to turn off plugin support. As well, this is an issue for the bookmark sidebar (not a webext thing)
I'm going to confidently resolve this bug WONTFIX. We're trying to get rid of windowed-mode plugins anyway, and the engineering work for this is not simple.