Closed Bug 1553444 Opened 5 years ago Closed 5 years ago

User Scripts do not work anymore from Firefox 69

Categories

(Core :: General, task)

69 Branch
x86_64
Windows 10
task
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox69 --- affected

People

(Reporter: milupo, Unassigned)

Details

Attachments

(3 files)

Hi,

in Firefox 69 user scripts do not work anymore. What's the reason? Is it intended to disable running user scripts forever?

Expected: User Scripts using userChrome.js should work.

How do you run it? What's the latest version that still works?

This post suggests it's a hack in 57+: https://www.ghacks.net/2017/11/24/run-userchrome-js-scripts-in-firefox-57-or-newer/

Component: JavaScript Engine → General

Mike, could this be related to bug 1550157? I know that mentions .css not .js ....

edit: oh after reading more of that post in comment 1, it's definitely a hack :/

Flags: needinfo?(mconley)

Hi Jan,

the last working version is Fx 68. Only from Firefox 69 scripts do not work anymore, partially or completely, even in a new profile. One reason could be this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1534407 - it's about enabling browser.xhtml instead of browser.xul. But userscripts that do not reference to browser.xul do not work, either.

If you're using the XBL trick described in the blog post, that's completely unsupported and we're actively removing XBL so even if it worked now it would break in a few weeks/months.

(In reply to Jan de Mooij [:jandem] from comment #4)

If you're using the XBL trick described in the blog post, that's completely unsupported and we're actively removing XBL so even if it worked now it would break in a few weeks/months.

Which blog post? And, which XBL trick?

(In reply to Michael Wolf from comment #5)

Which blog post? And, which XBL trick?

I meant the article in comment 1.

The userChrome.css file here uses XBL https://github.com/nuchi/firefox-quantum-userchromejs/blob/master/userChrome.css -- if you're using a file like that it's going to break sooner rather than later anyway. If you don't use this I've no idea what's going on :)

userChrome.css and userContent.css is another thing. A pref exists for them now since Fx 68. And -moz-binding does not work from Fx 68 on. That's not the problem. The problem is about user scripts which are imported by the file userChrome.js.. Those scripts have the file extension .uc.js (scripts with .uc.xul do not work anymore).

Ah okay, nevermind then. As you can see I'm not familiar with this, but I'm sure mconley will know more...

(In reply to Jan de Mooij [:jandem] from comment #8)

Ah okay, nevermind then. As you can see I'm not familiar with this, but I'm sure mconley will know more...

No problem. I'm not really familiar with this, either. :-) I'm a user of such JavaScripts only.

Hi jandem, Michael,

Bug 1550157 sets a pref to true if we notice that a user profile has either userChrome.css or userContent.css in their profile directory, and does nothing else. That landed in Firefox 68, and would not have caused Michael's problem.

Bug 1541233 has not yet landed, but will do the work of avoiding loading userChrome.css or userContent.css unless that preference is set. This has not yet landed, so that's not what Michael is hitting here.

Michael - how are you using userChrome.js? How were you getting it to load?

Flags: needinfo?(mconley) → needinfo?(milupo)

Hi Mike,

please have a little patience. I will prepare you a short attachement. Thanks.

Flags: needinfo?(milupo)

Hi Mike,

the file userChrome.js is one file of 5 files. It must be in the chrome folder of the profile directory and loads all scripts (.uc.js) which are in the same chrome folder. Its content is:

// userChrome.js
userChrome.ignoreCache = true;
userChrome.import("*", "UChrm");

Additionally following files exist:

  • config.js - must be in the root of the installation directory
  • config-prefs.js - must be in installation directory as well but in defaults --> pref
  • folder userchromeJS - must be in the root of the installation directory, as file config.js

Only the file userChrome.js and all script files have to be in the chrome folder of the profile directory

I attach file firefox-customizations.zip which contains all files.

This is a short script as example. It usually creates a blue button in the tool bar and you can simply restart Firefox (left click) or restart Firefox with clearing the script cache (middle and right click).

It looks like config-prefs.js sets general.config.filename to config.js, which bootstraps the loading of the userChromeJS stuff.

Hey mkaply, did any of this stuff change recently? This is mostly out of curiosity... I realize we don't support userChromeJS out of the box, but I'm kinda interested in knowing what broke this.

Flags: needinfo?(mozilla)

Nothing related to config files has changed for 69.

My guess is there's some other random thing breaking this.

Are there errors on the JS console?

Flags: needinfo?(mozilla)

It seems that the issue has to do with these two settings in about:config:

devtools.console.stdout.chrome
devtools.console.stdout.content

They have to be set to true but it seems that - after I retoggled to false - the script works, though. In the RestartFirefoxBvutton script I have to change browser.xul to browser.xhtml.

This script does not have a reference to a XUL file. It offers a list of Firefox settings. The only reference to XUL I find in line 344 and 345 (XUL_NS). The script icon (a yellow pen) should appear behind the url bar. It partially works in Fx 69 if you use the value 'menu' for the variable warpmenuto in line 19. Then a menu item "Config Menü" will appear in the Tools menu.

Bizarre. I have no idea why that would be.

However, as userScriptJS is not technically a Mozilla project, and is definitely not something we officially support, I'm going to close this bug out as INVALID. I suggest reaching out to the folks on Mozillazine for support - they might have some ideas for what went wrong with your userChromeJS customization, and what you need to do to keep it working.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

Hi Mike,

what a pity. Nevertheless, thank you for your help, although there is no official support for user scripting.

Hi Mike,

Late but not too late :-) I have an information for you. Reason for the issue in the script of comment 18 is a new script method: createElement must be createXULElement now - except createElementNS, this remains createElementNS. The script works again - the script icon is displayed, the list items are shown and work. Nevertheless, thank you for your help once more.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: