RemoteCocoa: Implement NativeWidgetMac::ReorderNativeViews on mojo
This fixes a bug where docked DevTools in PWAs doesn't work (and would affect anything that attempts to put two WebContents in a PWA). This function was never implemented because it involved passing a map of NSView*s over mojo. Since various refactorings, we now have a ScopedNSViewIdMapping which helps with this. Starting at the bottom of the change's stack and working to the top: * Change NativeWidgetNSWindowBridge::SortSubviews to take a std::vector of NSView ids, instead of a std::map ranking NSView*s. In the function, create the std::map ranking from the std::vector. * Change the caller, NativeWidgetMacNSWindowHost::ReorderChildViews. to build a std::vector of NSView*s, and then from that create a std::vector of NSView ids. * If the NSView*s do not have an id (that is, if they are not a WebContentsView, which only happens in tests), then create a temporary remote_cocoa::ScopedNSViewIdMapping to create an id. * Rename NativeWidgetMacNSWindowHost's SetAssociationForView, ClearAssociationForView, and associated_views_ to reflect that the "associated views" are a map from views::NativeViewHosts (a subclass of views::View) and NSView*s. Then there is an iffy part of the change * Allow looking up an NSView's id (the uint64 that is sent over mojo to refer to the NSView) from the NSView. * Arguably, we should change gfx::NativeView to also carry an id with it. But that is a too-large-scope change for now. Bug: 991598, 1017446 Change-Id: I2371d1716f98c2e6223a5db0272984c98c6fa4db Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1885950 Commit-Queue: ccameron <ccameron@chromium.org> Reviewed-by:Elly Fong-Jones <ellyjones@chromium.org> Reviewed-by:
Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/heads/master@{#710365}
Showing
Please register or sign in to comment