So I did a little more digging, and found that this actually first cropped up in Ubuntu 17.10.

I then ran mozregression (back on 18.04, my main desktop) and here’s what it found:

7:12.48 INFO: Last good revision: 64bab5cbb9b63808d04babfbcfba3175fd99f69d (2017-10-25)
7:12.48 INFO: First bad revision: aa958b29c149a67fce772f8473e9586e71fbdb46 (2017-10-26)
7:12.48 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=64bab5cbb9b63808d04babfbcfba3175fd99f69d&tochange=aa958b29c149a67fce772f8473e9586e71fbdb46

After that ”There are no build artifacts on inbound for these changesets (they are probably too old).”

As this was my first time ever using mozregression, I have no idea how useful that was, but if there’s some way I can narrow this down further, I’d be happy to.

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.

Thanks Olivier, I’ve now added the link to my upstream report.

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.

My test blog is running WP 5.0-beta3-43867 with Gutenberg 4.3.0-alpha-0841246 (from Daniel Bachhuber’s nightly), and the theme I’m using is Cover2 (Github here), which also appears to exhibit this in single post view.

I’ve narrowed it down to this function (called from header.php), where the gutenberg_parse_blocks() call triggers the issue.

I’m not saying I’m 100 % sure it’s Gutenberg and not the theme(s) at fault here, but I just thought I’d post this just in case it helps to find out either way.

LO 1:6.0.6-0ubuntu0.18.04.1 in Bionic is likewise affected, and the workaround also works here.

Amended to replace whitespaces mixed with tabs in extension.json, and to fix description message id.

Refactor file structure so that the extension can be loaded using MW 1.25+ style wfLoadExtension(), and makes MW 1.25+ a requirement. Otherwise the core functionality should remain just as it was (i.e., if it doesn’t, that’s unintentional on my part).

This closes issue #3.

Since MediaWiki 1.25, the suggested method of registering extensions has been to use wfLoadExtension() instead of a direct require_once. AddBodyClass currently (v1.2.0 from 2016-03-21) still uses the old style, so I’m opening this issue to suggest converting the extension to use the new method.

I’m also preparing a pull request with the minimal changes that I think should accomplish this, and I’ll post it next.