Closed Bug 1448669 Opened 6 years ago Closed 5 years ago

Broken userscripts since nightly from march 21/22 (only Windows?)

Categories

(Core :: Preferences: Backend, defect)

61 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: AngelOfDarkness, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180325100345

Steps to reproduce:

autoupdate nightly march 22.


Actual results:

mostly/all userscripts from /chrome are broken 


Expected results:

all scripts are normally running ;)
All users from the German forum (camp-firefox.de/forum) who uses userscripts on windows has the same problem. Sören Hentzschel has no problem with userscripts on MacOS.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
20180325130758

userChrome.js scripts are unsupported and bound to stop working once XBL support is completely removed (bug 1397874). For that matter, developers are also intent on removing userChrome.css (which allows loading the scripts), though I don't think there's a bug filed for that yet.


That being said, they still work for me. Here's an easy way to test:

1. https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles
Create a new profile.

2. https://luke-baker.github.io/#usage
Extract Firefox_chrome.zip into that profile. It should create the chrome folder, and inside there, userChrome.css, userContent.css, and userChrome.xml

3. https://luke-baker.github.io
Save the cookie button script into that chrome folder.

4. If Firefox is currently running in the new profile, restart it. You should see the cookie button on the navigation toolbar.
@Gingerbread Man

thx for ya comment and help, but your way describes the way with the userChrome.xml, but I and the others from the German forum use the possibility to place the files config.js and userChromeJS.js inside the Firefox program directory and to set there the files config-prefs.js inside /defaults/pref. And then after a restart of Firefox you can use userscripts *.uc.js from the profile/chrome.
Anyway your way doesn't work and the other way also not (on Windows.
So only we can do is to hope the new userScript API (see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1437098) or any other future API will return the same possibility ;)

BTW ... the userChrome.css is not affected
Something new...

the scripts dosn't work in the first windows. Will a new (second) window opened with Ctrl+N the scripts are back and running (most of them).
Damned .. how can I use mozregression with the userscripts adjustments ? To use mozregression only with the downloaded builds has no effect for user scripts :(
(In reply to AngelOfDarkness from comment #3)
> your way doesn't work

If you really did test in a brand new profile, the only difference between our setups should be the locale. Does your Windows user folder contain non-ASCII characters (umlauts for example)?

> So only we can do is to hope the new userScript API (see bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1437098) or any other future
> API will return the same possibility ;)

That has nothing to do with running scripts in the chrome. It's for web page scripts.

(In reply to AngelOfDarkness from comment #5)
> how can I use mozregression with the userscripts adjustments ?

1. Create a brand new profile but don't launch Nightly in it.
https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles

2. While Nightly is closed, use File Explorer to copy the contents of your profile with the user scripts into the brand new profile folder.

3. Launch mozregression-gui.
https://mozilla.github.io/mozregression/quickstart.html

4. Click the first toolbar button (run a new bisection).

5. Click Next.

6. Next to "Profile:" click the Browse button and pick the duplicate profile folder you created earlier.
Next to "Profile persistence:" select "reuse"
Click the Next button.

7. Select the last good build date and the first bad build date. I recommend choosing -1 and +1 day respectively, to be safe.
Click the Finish button to start.
@Gingerbread Man

Sure I tried a new profile ;)
I now that the new API will be for page codes, but I and many others hope that there'll be a API also for userscripts like userChromeJS.js ;)
Thx for the manual, but I tried it so. But the downloaded build aren't prepared for running userscripts. So all builds will be bad.
In the meanwhile aborix, a community member, had modified the main.js in /userChromeJS. So all scripts are full functionally back at the first firefox start.
You can use the testing method at comment 6 with the userChrome script method at comment 2. If you're not using mozregression, you also need to remove the autoconfiguration files (e.g. local-settings.js and mozilla.cfg or whatever you named them); a brand new profile isn't enough for a clean test.

I can't think of a way to automate testing the autoconfiguration files. I would
1. Use mozregression-gui to start a new bisection.
2. Once a build has launched, use File Explorer to open the %TEMP% folder and find the folder the build is running out of. Then copy the autoconfiguration files there and in …\defaults\pref
3. In mozregression-gui, click the "other…" button and choose "retry" to relaunch the build with the autoconfiguration files applied.

Since you're no longer experiencing the issue, I'd close this as Worksforme.
Component: Untriaged → Preferences: Backend
Product: Firefox → Core

(In reply to Gingerbread Man from comment #8)

Since you're no longer experiencing the issue, I'd close this as Worksforme.

No response from reporter in over a year, no regression range, no clear STR, and some of the testing steps I suggested previously aren't even applicable anymore.

(In reply to MarjaE from comment #9)

I lost safety settings in Stylus.

This has nothing to do with user styles.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.