location box dropdown displays on wrong monitor

Bug #1321903 reported by Joe Barnett
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Medium
firefox (Ubuntu)
Undecided
Unassigned

Bug Description

if I have a firefox window toward the left side of my right monitor, when I type something in the location box, the dropdown shortcuts appear on the rightmost edge of the left monitor. If i move the firefox window further toward the middle/right side of the right screen, it appears below the location box as it should. The boundary appears to be around 1450 pixels from the left hand side of the right screen.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: firefox 30.0+build1-0ubuntu0.14.04.3
ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11
Uname: Linux 3.13.0-27-generic x86_64
NonfreeKernelModules: nvidia wl
AddonCompatCheckDisabled: False
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: jbarnett 2982 F.... pulseaudio
 /dev/snd/controlC0: jbarnett 2982 F.... pulseaudio
 /dev/snd/controlC1: jbarnett 2982 F.... pulseaudio
BuildID: 20140428193813
Channel: Unavailable
CurrentDesktop: GNOME
Date: Wed May 21 12:35:18 2014
Extensions: extensions.sqlite corrupt or missing
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
InstallationDate: Installed on 2014-02-24 (86 days ago)
InstallationMedia: Ubuntu-GNOME 14.04 "Trusty Tahr" - Alpha amd64 (20140218)
IpRoute:
 default via 10.9.0.1 dev wlan0 proto static
 10.9.0.0/23 dev wlan0 proto kernel scope link src 10.9.0.55 metric 9
Locales: extensions.sqlite corrupt or missing
PrefSources:
 prefs.js
 /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/<email address hidden>/defaults/preferences/001ubuntu-gnome-mods.js
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=29.0/20140428193813 (In use)
RunningIncompatibleAddons: False
SourcePackage: firefox
Themes: extensions.sqlite corrupt or missing
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:

dmi.bios.date: 10/18/2013
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP112.88Z.0138.B02.1310181745
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-2BD1B31983FE1663
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro11,3
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-2BD1B31983FE1663
dmi.modalias: dmi:bvnAppleInc.:bvrMBP112.88Z.0138.B02.1310181745:bd10/18/2013:svnAppleInc.:pnMacBookPro11,3:pvr1.0:rvnAppleInc.:rnMac-2BD1B31983FE1663:rvrMacBookPro11,3:cvnAppleInc.:ct10:cvrMac-2BD1B31983FE1663:
dmi.product.name: MacBookPro11,3
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

Revision history for this message
In , csslayer (wengxt) wrote :

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131221082715

Steps to reproduce:

I'm using two screen with setup 3200x1800 on the left and 1600x1200 on the right under linux. DPI is set to 228 so by default right click menu height would only be a little bit smaller than 1200.
When devPixelsPerPx is larger than 1, firefox seems to think the screen size also times the factor. Which makes window in the right screen think they are in the left screen.

Actual results:

in my screen resolution setup, if devPixelsPerPx is set to 1.2, after right clicking on a window in 1600x1200 screen, clicking on the left part would show menu in the first screen, while the right half click would show menu in the right screen.

if devPixelsPerPx is set to some larger number (for instance 2), all popup menu that should be shown in the right screen would be shown in the left screen.

Expected results:

menu appears in correct screen.

Revision history for this message
Joe Barnett (thejoe) wrote :
Joe Barnett (thejoe)
description: updated
description: updated
Revision history for this message
In , Xidorn+moz (xidorn+moz) wrote :

Created attachment 8579169
screenshot

Revision history for this message
In , Xidorn+moz (xidorn+moz) wrote :

It seems this bug has been fixed in Aurora.

Revision history for this message
In , Liam Middlebrook (liammiddlebrook) wrote :

Created attachment 8639968
2015-07-28-103032_5520x3840_scrot.png

Revision history for this message
In , Liam Middlebrook (liammiddlebrook) wrote :

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0

On the black penciled line (in the image I've attached above) is where the separation occurs for a `devPixelsPerPx` value of 1.2. I've only encountered this issue on `devPixelsPerPx` values that are between 1 and 2. It appears that this invisible line of separation changes it's x position on a linear scale based on the value of `devPixelsPerPx`

Revision history for this message
Joe Barnett (thejoe) wrote :

this also affects hover text, right click context menu, allow/block plugins popups, etc

Revision history for this message
Joe Barnett (thejoe) wrote :

this seems to be related to me customizing layout.css.devPixelsPerPx as per upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=1068390

Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , 6-adv (6-adv) wrote :

Reproduceable on Firefox 43.0 for any values of devPixelsPerPx between 1 and 2 (excluding 1.0 and 2.0).

Revision history for this message
In , Cirdeiliviu (cirdeiliviu) wrote :

*** Bug 1068390 has been marked as a duplicate of this bug. ***

Changed in firefox:
status: Confirmed → Invalid
Revision history for this message
In , Overholt-u (overholt-u) wrote :

I see this on Windows, too. It feels like it *started* happening with a multi-dpi setup but now I'm seeing it without an external monitor connected, too.

Revision history for this message
In , Overholt-u (overholt-u) wrote :

William, is this a DOM thing or a Toolkit (?) thing?

Revision history for this message
In , R-william (r-william) wrote :

I don't see anything that indicates this is a DOM thing. My guess is that we are getting some numbers wrong in layout/xul/nsMenuPopupFrame.cpp

Revision history for this message
In , Xidorn+moz (xidorn+moz) wrote :

jfkthame, as you are recently working on Windows multi-dpi support, I suppose you have some insight around this issue.

Revision history for this message
In , Jfkthame (jfkthame) wrote :

It's possible the upcoming patches in bugs like 1240533 and 1247335 may help here. If not, I'll try to look into it further; I think there may be additional issues specific to resolution support in the Linux widget backend.

Revision history for this message
In , Rick-ramstetter+github (rick-ramstetter+github) wrote :

Confirming on Ubuntu 16.04, Firefox 46.0.1 X86-64.

Revision history for this message
In , Jhana2017 (jhana2017) wrote :

This seem to be a duplicate of 61000

Paul White  (paulw2u)
Changed in firefox:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.