User Scripts do not work anymore from Firefox 69
Categories
(Core :: General, task)
Tracking
()
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.
Comment 1•5 years ago
|
||
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/
Comment 2•5 years ago
•
|
||
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 :/
Reporter | ||
Comment 3•5 years ago
|
||
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.
Comment 4•5 years ago
|
||
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.
Reporter | ||
Comment 5•5 years ago
|
||
(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?
Comment 6•5 years ago
|
||
(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 :)
Reporter | ||
Comment 7•5 years ago
|
||
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).
Comment 8•5 years ago
|
||
Ah okay, nevermind then. As you can see I'm not familiar with this, but I'm sure mconley will know more...
Reporter | ||
Comment 9•5 years ago
|
||
(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.
Comment 10•5 years ago
|
||
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?
Reporter | ||
Comment 11•5 years ago
|
||
Hi Mike,
please have a little patience. I will prepare you a short attachement. Thanks.
Reporter | ||
Comment 12•5 years ago
•
|
||
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.
Reporter | ||
Comment 13•5 years ago
|
||
Reporter | ||
Comment 14•5 years ago
|
||
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).
Comment 15•5 years ago
|
||
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.
Comment 16•5 years ago
|
||
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?
Reporter | ||
Comment 17•5 years ago
|
||
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.
Reporter | ||
Comment 18•5 years ago
|
||
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.
Comment 19•5 years ago
|
||
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.
Reporter | ||
Comment 20•5 years ago
|
||
Hi Mike,
what a pity. Nevertheless, thank you for your help, although there is no official support for user scripting.
Reporter | ||
Comment 21•5 years ago
|
||
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.
Description
•