Emilio Cobos Álvarez 0b6ca42c5b Bug 1926624 - Unify top level widget behavior across platforms, standardizing on previous macOS behavior. r=stransky,mac-reviewers,win-reviewers,spohl,nrishel ... So the issue here is that my patch made GetTopLevelWidget() return the top level window across the widget chain, including this one in particular: https://searchfox.org/mozilla-central/rev/387f3edbef37d31b2e91fb0812c74b54729e86ff/layout/base/nsDocumentViewer.cpp#2339 We have two AppWindows parented: * Top level browser -> Alert window. It seems it's know that cocoa windows that aren't shown yet may have a HiDPI scale factor different from their actual screen's scale factor: * https://searchfox.org/mozilla-central/rev/387f3edbef37d31b2e91fb0812c74b54729e86ff/widget/cocoa/nsCocoaWindow.mm#1895-1935 This causes the alert window have a devicePixelRatio of 2 but the top level have a devicePixelRatio of 1. Which means that nsDeviceContext thinks we have a DPI of 1, but AppWindow and co have a DPI of 2, causing this mismatch. Fix this by making GetTopLevelWidget actually return the nsCocoaWindow widget for the alert, not the other. This restores the behavior for cocoa, but changes it for Windows and Linux (Android can't have nested top level windows, afaict). Given windows and Linux both had the concept of "top level widget" in a similar fashion, I think we can try this. I'll add a smaller fix for uplift purposes. Differential Revision: https://phabricator.services.mozilla.com/D227875		2024-11-08 09:29:26 +00:00
..
appshell	Bug 1926624 - Unify top level widget behavior across platforms, standardizing on previous macOS behavior. r=stransky,mac-reviewers,win-reviewers,spohl,nrishel	2024-11-08 09:29:26 +00:00