Adrian: Thanks for taking a look! I’m using Ubuntu 18.04, and that appears to be crucial here: I created a 16.04 VM, installed all in-release updates (including Firefox 63), and just as you, was unable to reproduce the issue. I then upgraded the VM to 18.04 and the bug immediately manifested again.
I first reported this against 62 in Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1798103
Firefox was since updated to 63 in Ubuntu and the issue remains.
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Steps to reproduce:
1. Open `about:config`, find `layout.css.devPixelsPerPx` and change the value from default (-1.0) to 1.2.
2. Open a view-source view with long lines: `view-source:https://www.youtube.com/user/10asti10`
3. hit Ctrl+f, search for rss
4. using the LMB, try selecting some text, then copy and paste it somewhere
Actual results:
After step 3, the highlighted text on the page is not ”rss”. The highlight doesn’t even adhere to letter widths (screenshot 1).
After step 4, the pasted text is not even close to what you’ve selected to copy.
Expected results:
For the search to hightlight an occurence of ”rss”, and for the pasted text to correspond to what I’ve selected from the view-source view.
== The issue ==
Search and text selection highlighting visuals get mismatched with the actual selection in view-source when the value of `layout.css.devPixelsPerPx` is 1.2 or larger.
== Steps to reproduce ==
* Open `about:config`, find `layout.css.devPixelsPerPx` and change the value from default (-1.0) to 1.2.
* Open a view-source view with long lines: `view-source:https://www.youtube.com/user/10asti10`
* hit Ctrl+f, search for rss
* using the LMB, try selecting some text, then copy and paste it somewhere
== What happens ==
Screenshot 1: the highlighted text on the page is not ”rss”. The highlight doesn’t even adhere to letter widths.
Screenshot 2: the pasted text is not even close to what you’ve selected to copy.
== What I expect to happen ==
For the search to hightlight an occurence of ”rss”, and for the pasted text to correspond to what I’ve selected from the view-source view.
== Other info ==
* In my testing, a devPixelsPerPx value of 1.1 seems to not trigger this, whereas 1.2 and anything above does.
* In addition to 18.04 (whence the attached info is from) I’ve reproduced this in a VM running up-to-date 18.10.
Alright, from my brief testing it would seem this does not reproduce under Wayland.
My recipe above appears to be quite sensitive to details: I have a test user with a clean desktop (with little more customization apart from the extension), and there the recipe works just as written. On the other hand, with my main user account it doesn’t. To clarify: while the steps listed above fail to reproduce the issue with my main account, my main account does manifest the issue too; just not with those exact steps.
My main account starts up the Signal desktop client, Nextcloud client and some other stuff upon login, but so far I haven’t found which of those (if any) causes this difference.
I was, however, able to reproduce the ”see-through hole” effect under both accounts: instead of maximizing Gnome terminal (in step 3), I tile it to cover the left half of my screen, then start up Chrome/Firefox, tile itover the terminal window (i.e. to also cover the left half of the screen), before turning the display off and on again. Firefox then also manifests the hole, as does Gnome terminal when brought back to foreground from below. (Chrome does not manifest the hole, but then again Chrome has always appeared oblivious to the extension here.)
I should mention that I’m leaving the display off for about 4-5 seconds before turning it back on again. I’m not sure if that makes any difference, I’m just doing to to be sure that the ”I’m off” signal has time to propagate back to the system.
Background
I’m using the currently published version of No Title Bar from Gnome Extensions in Ubuntu 18.04 (gnome-shell version 3.28.1-0ubuntu2).
Steps to reproduce
- log in to desktop
- start Gnome terminal
- maximize the terminal window (so that the title bar merges with the activity bar)
- power the display off, then back on
What happens
The terminal window again has its own title bar.
What I expect to happen
For the terminal window title bar to remain merged with the activity bar.
Further info
Under some circumstances (the specifics of which I haven’t been able to narrow down), when the title bar comes back, it is entirely transparent, so that in place of a title bar you have a see-through hole. Here’s a screenshot, showing how part of Firefox’s UI is visible from behind the terminal window, through where the title bar would be.
Background
I’m using Ubuntu 18.04 with Gnome Shell 3.28.1, and was forwarded here from Launchpad, see bug #1767806 there.
The issue
When another window is maximized or tiled to the left side of the screen, re-opening an application whose window was previously tiled to the left side does not restore that windows’ previous position. Instead such windows open at varying distances from the dock, untiled.
Expected behavior
Steps to reproduce (with a newly created user)
- open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
- close Firefox
- open Nautilus, make sure that the window floats (i.e. is unmaximized and not tiled to either side of screen)
- open Firefox
What happens
As expected, Firefox’s window is tiled to the left edge of screen, immediately to the right side of the dock: screenshot.
Unexpected behavior
Steps to reproduce (with a newly created user)
- open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
- close Firefox
- open Nautilus, maximize its window
- open Firefox
What happens
Firefox’s window opens slightly to the right off the right edge of the dock (with a gap between the dock and the window): screenshot.
What I expect to happen
I expect Firefox’s window to be tiled to the left edge of screen, immediately to the right side of the dock, just as it did following the first recipe above.
Further information
- Either maximizing or tiling Nautilus’ window to the left edge of the screen (at step 3) triggers the issue. Tiling it to the right edge of the screen does not.
- Using Gnome Terminal instead of Nautilus triggers the issue just as well and I suspect any other application will, though I’ve only systematically tested these two so far.
- From battling with this in my daily use I also know that the distance of incorrectly restored windows from the dock varies: different applications open at different distances. The precise mechanics of this still elude me, though the distances do appear to be multiples of 25 pixels.
In addition to Totem, Firefox also exhibits this with fullscreen HTML5 video. Here’s a good test: https://www.youtube.com/watch?v=5xkNy9gfKOg
Haven’t seen this since upgrading to 18.04, and can’t reproduce it following the instructions anymore either, so it appears to be fixed.
Impacted version: 0.60
Server Setup Information:
- Operating System: Ubuntu 16.04
- Deployment Method: snap
- ROOT_URL environment variable (Is there a subfolder?): https://my-domain.com/kan (yes)
Problem description:
A description consisting entirely of a URL that happens to extend from the left edge to the right edge of the description field makes it impossible to edit the description, as clicking anywhere on the viewer lands the click on the URL, which triggers a new browser tab instead of the editor.
Here’s a screenshot of such a URL overlapping the editing area, as highlighted by the inspector in Firefox.

There’s actually a couple of pixels worth of unlinked, clickable editor area at the right edge here, but you need a really steady hand and mouse to hit those pixels.
A workaround seems to be to change the browser zoom level (either way), causing the URL to extend either over to the next line or properly short of the right edge of the first line (turning the rest of the line clickable).