Firefox: Microsoft Answers is broken

[PowerWeb5]

Even when I have no styles installed and have disabled Stylus via the "Turn all styles off" option, its scripts and I believe CSS are still injected into, running, and completely break some websites like Microsoft Answers. You can see this at the following page, by logging in and then clicking Reply.

You will see that Submit and Cancel buttons for the Reply fail to work, as well as text editor dialog overlays like Insert Hyperlink's Insert and Cancel buttons fail to work/close that dialog (as can be seen after clicking the Insert Hyperlink text editor toolbar button).
There is a spinning waiting indicator shown forever above the Submit button that only occurs when Stylus is installed..

I have reproduced this issue with both Stable and Developer Editions of Firefox.

Page Where Issues Occurs (Begin Editing a Reply to See the Issue):

https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/microsoft-mouse-keyboard-center-v30-will-not/1cbc5891-0c23-4cbb-99f2-fb5729850bf7

My Configuration

• Stylus v1.1.0
• Firefox Developer Edition x64 v55.0b2 (but also occurs with stable Firefox release)
• Windows 10 x64

[tophf]

I can see it in FF55 dev intermittently, and in standard FF, but not in Chrome. I see no obvious problems in our content script code, I don't use FF either, so setting the meta accordingly. On a side note, it's kinda possible to remove our content script in FF by switching to chrome.tabs.insertCSS and removeCSS, but those functions are really dumb, I've already tried switching and concluded that the limitations/drawbacks defeat the gains.

An angle to pursue: the site contains two iframes so it's possible FF handles content script injection differently or incorrectly, thus breaking the functionality.

[schomery]

Even with a completely empty "apply.js", still, this spinning occurs. Unless we change to code to not inject apply.js at all when Stylus is globally off, there is no way to fix this issue.

Since you are going to have this issue will all other WebExtension add-ons that are injecting scripts into web pages, I would say open a bug report in Bugzilla. This is not a Stylus specific issue.

[tophf]

FWIW switching to programmatic injection would mean removing the automatic injection in manifest, and my old tests showed a noticeably bigger delay leading to a frequent FOUC. This might have changed since. Not that it will guarantee the FF bug can be circumvented, though.

[schomery]

Switching to programmatic injection is a mess. I would say it is better to not go that direction unless we really have to.

[tophf]

"all_frames": true is what triggers the FF bug.
It affects all WebExtensions that use this setting for their content scripts. Like thousands?

OTOH the MS site uses quite a weird src='javascript:""' for the iframe so I'm not surprised FF stumbles on that.

[tophf]

Fixed in FF 58 Nightly.

[grahamperrin]

Fixed in FF 58 Nightly.

Without me resorting to mozregression (or the like) … please, do you know which changeset included the fix?

Context: https://redd.it/akpg72 involving some versions of Waterfox, not all users; Waterfox 56.0 was based on Firefox 56.0.2 and we're now at Waterfox 56.2.7.1.

[tophf]

Alas, I didn't investigate it.

[grahamperrin]

OK, thanks for the quick response.

Found: Mozilla bug 1397399 - unable to reply to post at answers.microsoft.com with AdBlock Plus add-on enabled RESOLVED DUPLICATE of 1379148 - document.write does not synchronously modify a document if an extension has content scripts at document_start

• 56 Branch
• regression
• VERIFIED FIXED in mozilla58
• fixed at https://bugzilla.mozilla.org/show_bug.cgi?id=1379148#c52 with reference to four mozilla-beta changesets.

1379148

https://github.com/MrAlex94/Waterfox/search?q=1379148&type=Commits finds eight commits but I shouldn't assume that they're effective.

Considering that I can not reproduce the issue with an unofficial build of Waterfox ~56.2.7.1 on FreeBSD-CURRENT:

grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Tue  5 Feb 2019 06:49:38 GMT
FreeBSD 13.0-CURRENT r343308 GENERIC-NODEBUG 
grahamperrin@momh167-gjp4-8570p:~ % find /usr/local/poudriere/ports/default/www/waterfox/files -name "*1379148*" 
/usr/local/poudriere/ports/default/www/waterfox/files/patch-bug1379148
grahamperrin@momh167-gjp4-8570p:~ % 

– just one file.

https://www.freshports.org/www/waterfox/Makefile ▶ https://svnweb.freebsd.org/ports?view=revision&revision=461852 ▶ https://svnweb.freebsd.org/ports/head/www/waterfox/files/patch-bug1379148?view=markup&pathrev=461852 with reference to MozReview-Commit-ID: 8cGxywiUzWj

https://github.com/search?q=org%3Amozilla+8cGxywiUzWj&type=Commits finds two commits.

---

FreeBSD aside: I can reproduce the issue with (extended) Waterfox 56.2.7.1 on Lubuntu so I'll take this to the GitHub repo for Waterfox.