1186145 - Firefox opens up absolutely HUGE such that version 38 and 39 are unusably large on a typical laptop screen!

Status: RESOLVED INACTIVE

(Core :: Widget: Gtk, defect, P2)

Description

[jzamitini]

Attachment: firefox_3x_huge_bug_firefox_37vs38_new_user.jpg

Firefox opens up absolutely HUGE such that version 38 and 39 are unusably large on laptop screens!

Firefox versions equal to and above version 38 consistently display unusably about 3x huge size on Kubuntu 14.04 (KDE 4.13.3) even when using Firefox safe mode, with a new Linux user account, and no previous $HOME/.mozilla directory.

It seems that the two observations: 
1. HUGEZOOM level, and, 
2. HUGEBORDERS 
Are, apparently, exactly the same bug which shows up between FF 37 and FF38.

The bug exists on FF38 and FF39; and the bug does NOT exist on FF37 and FF35.

Here is the result of FF38 & FF37 on a brand new virgin user account: 
Screenshot URL: http://i.imgur.com/DYxTKth.jpg  
Attached file: firefox_3x_huge_bug_firefox_37vs38_new_user.jpg

Here are the two versions of Firefox 38 and 37 run moments apart with Google as the home page:
Screenshot URL: http://i.imgur.com/h63JydT.jpg 
Attached file: firefox_3x_huge_bug_firefox_39vs35_new_mozilla_dir.jpg

Here you see two versions running simultaneously where one is 3x the other in default size:
Screenshot URL: http://i.imgur.com/LMm76LZ.jpg 
Attached file: firefox_3x_huge_bug_firefox_38vs35_new_instance.jpg

The two issues of huge borders and huge zoom consistently show up as here, between FF39 & FF35:
Screenshot URL: http://i.imgur.com/RMoJW86.jpg 
Attached file: firefox_3x_huge_bug_firefox_39vs35_troubleshooting.jpg

Even the FF39 “About Firefox” version popup is huge, in comparison to FF35, FF36, and FF37:
Screenshot URL: http://i.imgur.com/h63JydT.jpg 
Attached file: firefox_3x_huge_bug_firefox_39vs35_about_firefox.jpg

The only thing that overtly changes is the FF version: 
1. It happens with every FF version tested at or above version 38. 
2. It does not happen with every FF version tested at or below 37. 
3. It does not matter what user.
4. It does not matter if I first blow away the ~/mozilla directory.

I have tested this bug over a span of two weeks for about a dozen hours and it is very consistent; but it's not in all operating systems and versions!

In fact, this bug ONLY occurs in 64-bit Firefox 38 and above (I tested versions 38 & 39); and does NOT occur in Firefox 37 and below (I tested down to and including Firefox 35).

This bug ONLY occurs on 64-bit Linux Kubuntu 14.04 (KDE 4.13.3) and this bug does not occur on other operating systems and versions that I have tested.

$ uname -a 
=> Linux 3.13.0-48-generic #80-Ubuntu SMP x86_64 GNU/Linux

$ kde4-config --version
=> Qt: 4.8.6
=> KDE Development Platform: 4.13.3
=> kde4-config: 1.0

$ lsb_release -d
=> Description:	Ubuntu 14.04.2 LTS

$ lspci
.... ....
01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2)

$ /usr/bin/nvidia-smi
Tue Jul 21 11:48:05 2015       
+------------------------------------------------------+                       
| NVIDIA-SMI 340.76     Driver Version: 340.76         |                       
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Quadro FX 880M      Off  | 0000:01:00.0     N/A |                  N/A |
| N/A   50C   P12    N/A /  N/A |    188MiB /  1023MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+

Clearly, the bug is that "something" in Firefox changed between versions 37 and version 38 such that Firefox is interacting with "something else" in Linux Kubuntu 14.04 (KDE 4.13.3) or with the Nvidia display driver to make the browser open up to a huge size, by default, which is about 3x the normal size (and which is, therefore, unusable, out of the box).

My current workaround is simply to use Firefox 37 and below (which works just fine). I have run MANY tests and this is consistent. I created a NEW USER and it still happened exactly as before, so it has NOTHING to do with the user files.

Since Firefox works perfectly at version 37 and below, it also "probably" has NOTHING to do with the operating system; but, I don't know what other Kubuntu users experience (I can't believe Firefox was never tested on Kubuntu 14.04 with KDE 4.13.3 so it may be a peculiar bug in Firefox).

I can easily reproduce the problem with a new user account and by opening up the 37 and older Firefox versions and the 38 and newer versions, side by side, at the very same time, and then screenshotting the results as shown below.
 
Usenet newsgroup: mozilla.support.firefox
Subject: What controls the Firefox 38/39 border size & default page zoom level?
Date: July 5, 2015
Reference: https://groups.google.com/forum/#!topic/mozilla.support.firefox/VWf242Bg6Nk

Usenet newsgroup: mozilla.support.firefox
Subject: Auuurgh! Firefox 38 undid my spacesaving efforts on FF37!
Date: July 1, 2015
Reference: https://groups.google.com/forum/#!topic/mozilla.support.firefox/6_CS7gXG-0A

Usenet newsgroup: alt.os.linux
Subject: Auuurgh! Firefox 38 undid my spacesaving efforts on FF37! 
Date: July 1, 2015
Reference: https://groups.google.com/forum/#!topic/alt.os.linux/qfPAx2-BEHg[1-25]

Comment 1

[jzamitini]

Attachment: Here is a screenshot of version 38 next to 35 at the same time, where any Firefox version at 38 or above is HUGE compared to any version at 37 and below.

Here is a screenshot of version 38 next to 35 at the same time, where any Firefox version at 38 or above is HUGE compared to any version at 37 and below.

Comment 2

[jzamitini]

Attachment: Here is the Firefox "about firefox" showing how huge the version 39 is next to the version 35 where the 39 isn't usable on a laptop screen.

Comment 3

[jzamitini]

Attachment: Here is Firefox 39 next to Firefox 35 with the $HOME/.mozilla directory blown away prior to invocation.

Comment 4

[jzamitini]

Attachment: Here are the Firefox 39 and 35 troubleshooting dialog boxes showing that the version 39 is HUGE compared to 35, with NOHTING else being different.

Comment 5

[Justin Dolske [:Dolske]]

Presumably this is a result of bug 975919. What pixel ratio does http://devicepixelratio.com/ report for you in Firefox 39?

Comment 6

[jzamitini]

Hi Justin,
Thank you very much for taking an interest in this, my very first bug report ever for Firefox. 
There is definitely "something" that changed between FF37 and FF38 that reacts with "something" else on my Kubuntu 14.04 system, that causes this anomaly. 

Since I can't find anyone else in my local circle who has this problem, I do realize it may be machine or operating system specific, so, I definitely appreciate any and all debugging commands you can provide for me to run and provide diagnostic results back to you.

As directed, I ran the following commands in sequence:
$ ./firefox_37.0/firefox/firefox -new-instance -P Firefox_37 -url http://devicepixelratio.com/ &
$ ./firefox_38.0/firefox/firefox -new-instance -P Firefox_38 -url http://devicepixelratio.com/ &
$ ./firefox_39.0/firefox/firefox -new-instance -P Firefox_39 -url http://devicepixelratio.com/ &

The results were the following:
FF37: Your Device Pixel Ratio is: 1 (With no viewport set.)
FF38: Your Device Pixel Ratio is: 2 (With no viewport set.)
FF39: Your Device Pixel Ratio is: 2 (With no viewport set.)

Please see the attached screenshot of simultaneous FF37 & FF39 results on Kubuntu 14.04:
 firefox_37_vs_39_pixelratio_test_results.jpg
 http://i.imgur.com/FbN0Uu4.jpg

Comment 7

[jzamitini]

Attachment: This is a screenshot of FF37 & FF39 simultaneously pointed to the web site devicepixelratio.

Comment 8

[Justin Dolske [:Dolske]]

The browser UI in your screenshots is exactly double the normal size, which is what would be expected on a screen with a device pixel ratio of 2.0. What kind of screen / laptop are you using?

I believe changing the layout.css.devPixelsPerPx pref in about:config from -1 to 1 should restore the previous sizing as a workaround.

Comment 9

[jzamitini]

Hi Justin, 
I agree with you that the size of FF38 & above appears to be 2X (not 3X as I had first described).
The laptop is a very common (older) Lenovo Thinkpad W510 
$ inxi -F
System:    Host: karl Kernel: 3.13.0-48-generic x86_64 (64 bit) Desktop: KDE 4.13.3 Distro: Ubuntu 14.04 trusty
Machine:   System: LENOVO (portable) product: 4318CTO version: ThinkPad W510
           Mobo: LENOVO model: 4318CTO Bios: LENOVO version: 6NET74WW (1.34 ) date: 10/27/2010
CPU:       Quad core Intel Core i7 CPU Q 720 (-HT-MCP-) cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) 
           Clock Speeds: 1: 933.00 MHz 2: 933.00 MHz 3: 933.00 MHz 4: 933.00 MHz 5: 933.00 MHz 6: 1600.00 MHz 7: 933.00 MHz 8: 1600.00 MHz
Graphics:  Card: NVIDIA GT216GLM [Quadro FX 880M] 
           X.Org: 1.15.1 drivers: nvidia (unloaded: fbdev,vesa,nouveau) Resolution: 1920x1080@60.0hz 
           GLX Renderer: Quadro FX 880M/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.76

Independently, after reading the bug report you suggested, I found the keyword "hiDPI" to search for and using that keyword I found the workaround you had suggested, which is explained here:
https://support.mozilla.org/en-US/questions/961160

It's confusing because that support article implies the change occurred at FF22, but, for me, the doubling-of-size bug happened in the switch between FF37 and FF38; nonetheless the suggested workaround works perfectly.

I started up FF39, and changed "layout.css.devPixelsPerPx;-1.0" from "-1.0" to "1"; and, for the first time since FF38 was released, the Firefox was USABLE on my laptop! Hooray! 

I'm still very confused how GTK is involved, since I'm using KDE; however, it may be important to note that this particular Linux laptop started out as a Ubuntu/Unity laptop (back in 2013) and was then upgraded to Kubuntu 13.10 and then to 14.04 over time; so maybe that's how GTK got involved?

Anyway, it's an important bug to warn users about because it makes anything above Firefox 38 unusable on a laptop screen, and wasteful (as I preserve up:down space which is CRITICAL on laptops!) by removing menus, and toolbars so that up:down premium space is preserved.

You'll note, as an aside, that my screenshots show ALL menus are off to the sides, which on a wide-screen laptop such as mine is, makes sense because NOTHING WHATSOEVER should use up space in the up:down direction. (The bug made Firefox use up far too much up:down space to be usable.)

Thanks for the workaround; please let me know what else I can do to debug why the bug occurred.

Comment 10

[jzamitini]

Hi Justin,
Your suggested devpix workaround is working out fine on FF39, so, now FF39 is finally usable! Hooray!
Let me know if you need more hardware information so that others don't have this problem in the future.
I found out from elsewhere that the GTK code that Firefox links in is what's responsible for the incorrect calculation of the DPI (not any code that is on my system); and I found out that by setting the devpix to "1", I'm telling Firefox to turn off its (incorrect) automatic calculation, and the "1" means that I'm manually telling Firefox to set the DPI calculation at 100% of 96 dpi (if I used, for example, 0.8, that would be telling Firefox to use 80% of 96dpi, or 77dpi, if I understand correctly how layout.css.devPixelsPerPx works).

Comment 11

[jzamitini]

I'm taking heat on the Usenet so would one of the Firefox developers simply confirm in this bug report whether this is a bug or not? Is sure seems like a bug, to me, but has a developer confirmed that this is, indeed, a bug?

Comment 12

[jzamitini]

It's important to note that the suggested bug report (975919) is about "implementing support for GDK's scale factor, which was introduced in GTK 3.10 (and thus is not currently riding the trains, as current release builds link against GTK2).", so, it's not clear to me WHY my Mozilla is having this problem in Firefox 38 and Firefox 39.

My Lenovo W510 Thinkpad laptop (model 4318CTO) has an EDID of 144 DPI, as shown here:
$ xdpyinfo | grep dots
=> resolution: 143x144 dots per inch

From "dillinger", I found out that the devpix ratio standard is set to 1 at 96 dpi. 
Since my monitor is at 144DPI, the math works out to 144/96 = 1.5 for my "correct" devpix ratio.
According to "dillinger", Firefox never calculated this ratio correctly.

Apparently, Thunderbird doesn't calculate it correctly either, but, that would be the subject of another bug report.

Since the aforementioned bug 975919 is for a *future* Firefox version (using GTK3), I would just like some clarity of *where* this bug that I'm seeing in FF38 and in FF39 on 64-bit Kubuntu/KDE lies.

That is, is this bug in the GTK2 code? 
Or, is this bug in the Mozilla code for FF38 and FF39?

Comment 13

[jzamitini]

To answer my own question above, I found out that Firefox uses XUL which uses GTK code.

Comment 14

[Thomas Daede [:TD-Linux]]

Can you try installing some other GTK3 app and see if it's using a scale ratio of 2.0? E.g. a newish version of nautilus or the like?

Comment 15

[Justin Dolske [:Dolske]]

I'm not familiar with GTK code, I just moved this to the right spot.

Comment 16

[Felix Miata]

Attachment: Kubuntu 14.04 @144 DPI screenshot: Xft.dpi = 96 & layout.css.devPixelsPerPx = -1.0

Both rvs started with empty profile directories.
rv17: right side Firefox window
rv48: left side & middle two Firefox windows

Comment 17

[Felix Miata]

Attachment: Kubuntu 14.04 @144 DPI screenshot: Xft.dpi = 96 & layout.css.devPixelsPerPx = +1.0

Same as the previous attachment, but after these actions:
1-layout.css.devPixelsPerPx changed from default -1.0 to 1.0
2-resize upper middle rv48 window
3-reload lower middle rv48 window

Note in both this and previous attachments the disparity between the Xft.dpi specification (96) and the Xorg server's calculated and reported 144 DPI logical pixel density. Xft.dpi, an interloper in the Xorg environment on which the Gnome environment apparently depends, is overriding the Xorg server's logical pixel density. 96 DPI is the density of CSS reference pixels, roughly equivalent to the physical pixel density of most pre-HiDPI displays. 144 DPI is typical of today's moderately high physical pixel density displays, such as the 141.3 DPI Thinkpad W510 used by the reporter. The Xft.dpi override results in application and desktop objects being smaller than intended for use with displays that are more nearly 96 DPI physically.

Comment 18

[Felix Miata]

Attachment: Kubuntu 14.04 @144 DPI screenshot: Xft.dpi Null & layout.css.devPixelsPerPx = -1.0

Both rvs started with empty profile directories.
rv17: right side Firefox window
rv48: left side & middle two Firefox windows

The foundational difference between this and the two previous attachments is KDE's use of the Xorg server's automatically generated 144 DPI logical display density, occurring through the absence of Gnome's environmental interloper, Xft.dpi. The result is UI objects and native KDE application objects are appropriately sized to the moderately high physical display density without any user need to adjust any desktop settings. The primary exception to appropriate automatic sizing lies within the rv48 viewport (the reporter's complaint), a consequence of the default -1.0 layout.css.devPixelsPerPx configuration.

Comment 19

[Felix Miata]

Attachment: Kubuntu 14.04 @144 DPI screenshot: Xft.dpi Null & layout.css.devPixelsPerPx = +1.0

Here can be seen vis-a-vis previous attachment rv48's viewport content repaired (mostly: "chrome" text upper left within the about:support viewport over-adapts to become undersized) by changing layout.css.devPixelsPerPx from -1.0 to +1.0.

Xft.dpi within KDE serves only one, entirely optional, legitimate purpose:
for individual users to override the Xorg server's automatically determined logical display density (which is how through its font settings it can force DPI).

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Jan is working on the Gtk/HiDPI issues right now.

Comment 21

[Jan Vlug]

Attachment: Fonts too large

I see problems with the size of Firefox (and Thunderbird) GUI elements and fonts as well on Gnome 3 on Wayland on Fedora 27, fully up to date. Setting the devPixelsPerPx from -1.0 to +1.0 fixed the fact of the GUI elements that are too large. But the fonts are still huge. See attachment.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1523944

Comment 22

[Jan Vlug]

Attachment: wrong_fonts.png

Another example of the huge fonts.

Comment 23

[Jan Vlug]

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1523944

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 25

[Gian-Carlo Pascutto [:gcp]]

Enough has changed in all involved applications that this is probably not actionable unless it is confirmed on a modern Linux distro with current Firefox.