Open Bug 1490285 Opened Last year Updated 10 months ago
The "meatball" menu is misplaced when Dev
Tools is zoomed out and displayed on the primary monitor
[Affected versions]: 64.0a1 (BuildId:20180910220142) 63.0b5 (BuildId:20180910132416) [Unaffected versions]: 62.0 (BuildId:20180830143136) 60.2.0esr (BuildId:20180903060751) [Affected platforms]: Windows 10 64bit. Ubuntu 16.04 64bit. [Preconditions] Have a dual display setup. [Steps to reproduce]: 1. Launch Firefox (have it displayed on the primary monitor). 2. Open the developer tools. 3. Minimize the Developer tools to the maximum by using the "CTRL" + "-" keyboard combination. 4. Click on the meatball menu. [Expected result]: The meatball menu opens under the meatball button. [Actual result]: The meatball menu is misplaced. [Regression range]: This seems to be a regression. Mozregression points out Bug 1461522 for causing this regression. Last good revision: ea72ff9a6e23abf3aa52aaaf06a9ba8b18ca39c7 First bad revision: cc6ec2789c9d50a686f4df5a70bf0f1173d1d32e Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ea72ff9a6e23abf3aa52aaaf06a9ba8b18ca39c7&tochange=cc6ec2789c9d50a686f4df5a70bf0f1173d1d32e [Note] For further information regarding this issue please observe the attached screencast.
Another multi-monitor issue.
Priority: -- → P3
See Also: → 1485501
Hi Emil, I modify the dual display issue in the bug 1485501. Could you please whether you can reproduce this. (I can't reproduce this phenomenon.) Thanks.
Hi Mantaroh, It seems that I can't reproduce this issue using Firefox 64.0a1 (BuildId:20181016220050) on Windows 10 64bit but this seems to be reproducible on Ubuntu 18.04 (using the same steps as in Comment 0 but on the secondary monitor).
(In reply to Emil Ghitta, QA [:emilghitta] from comment #3) > Hi Mantaroh, > > It seems that I can't reproduce this issue using Firefox 64.0a1 > (BuildId:20181016220050) on Windows 10 64bit but this seems to be > reproducible on Ubuntu 18.04 (using the same steps as in Comment 0 but on > the secondary monitor). Thanks! I'll look into this phenomenon in detail.
This phenomenon might be happen only if the primary monitor is the right position. I'm not sure yet this reason, it seems to me the calculated width of window and anchor rectangle is wrong.
We calculated the window and the viewport rectangle as logical position(i.e., not considering the zoom value). I tried dividing the window and viewport rectangle by zoom value: https://hg.mozilla.org/try/rev/63c74f551913f22332f988a780c2876c24278585
Assignee: nobody → mantaroh
Status: NEW → ASSIGNED
(In reply to Mantaroh Yoshinaga[:mantaroh] from comment #7) > We calculated the window and the viewport rectangle as logical > position(i.e., not considering the zoom value). > I tried dividing the window and viewport rectangle by zoom value: > https://hg.mozilla.org/try/rev/63c74f551913f22332f988a780c2876c24278585 This comment is wrong. We get the monitor geometry information by using monitor number. In this case, we use the primary display dimension as a left monitor dimension. For example: I have two monitors ( Primary is 2560x1440, Secondary is 3840x2160 ), and positioned the primary monitor to right. If I opened the browser on the right monitor, window.left and screen.availLeft is 2560px. (in spite of the left monitor is 3840px width.) This behavior is same as chromium.  https://searchfox.org/mozilla-central/rev/fcfb479e6ff63aea017d063faa17877ff750b4e5/widget/gtk/ScreenHelperGTK.cpp#196
Ah, GTK tell us the wrong second screen width.. [(null) 22280: Main Thread]: D/WidgetScreen New screen [2560 0 1712 963 (2560 27 1712 936) 24 1.000000 1.000000 143.883530] [(null) 22280: Main Thread]: D/WidgetScreen New screen [0 0 2560 1440 (0 0 2560 1440) 24 1.000000 1.000000 107.576469] I changed my backend from wayland to X11, then I confirmed that this phenomenon doesn't be happen.
The condition of this bug is the as follow: * Wayland environment. * The primary monitor positioned on right. Wayland is not the default backend on Ubuntu at the moment. (Ubuntu 17 enabled the Wayland, but 18.10 disabled) As a result of discussing with Birtles, I decided that making this bug to a low priority.
Priority: P3 → P5
Marking fix-optional for 64. We could still take a patch in 65.
Updating tracking flags as we get closer to the 64 release. Fix-optional for 65 as we only have experimental wayland support on Nightly, we are not shipping support for it in 65.
Assignee: mantaroh → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.