Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

56.2.0 20180514223240 can not re-enable extensions that require Firefox 57 or greater #560

Closed
grahamperrin opened this issue May 15, 2018 · 12 comments
Closed

56.2.0 20180514223240 can not re-enable extensions that require Firefox 57 or greater #560

grahamperrin opened this issue May 15, 2018 · 12 comments

Comments

@grahamperrin
Copy link

First run after installing 56.2.0 build 20180514223240 over 56.1.0.111172 on FreeBSD-CURRENT:

2018-05-15 02 52 52 waterfox update

2018-05-15 02 53 15 waterfox update

2018-05-15 02 53 37 waterfox update

2018-05-15 02 55 07 add-ons manager

… and so on, no Enable button for any of the five that are disabled …

2018-05-15 02 58 57 add-ons manager

I wondered whether Simple Add-on Manager would allow an override. Unfortunately not:

2018-05-15 03 00 04 group -1 - speed dial

For some of the extensions:

  • a downgrade will allow use, but (at least with Mobile Dyslexic) downgrading will lose functionality that was present with 56.1.0.

For the others:

  • no legacy version is available.
@MrAlex94
Copy link
Collaborator

MrAlex94 commented May 15, 2018 via email

@grahamperrin
Copy link
Author

grahamperrin commented May 15, 2018 •
edited
Loading

Perfect, thanks. I guessed that there would be a compatibility check workaround in prefs, but I was too lazy to figure it out for myself :-)

Result:

  • all five extensions automatically enabled immediately after adding the preference (none were disabled by me before the installation of 56.2.0)
  • at about:addons the yellow alerts remain –

⚠ Tip Tab is incompatible with Waterfox 56.2.0

– and so on. The alerts are proper, end power users may choose to ignore them.

@grahamperrin
Copy link
Author

grahamperrin commented May 15, 2018 •
edited
Loading

Postscript: ignore this comment. Apology/explanation below at #560 (comment)

Thoughts … for now (for the forthcoming general release), is it possible to include extensions.checkCompatibility.56.2 true by default but false on first run of 56.2.0?

Rationale:

  • it is the type of check that should be made when refreshing 56.2.0.

For 'power users' we can have, amongst FAQ, a shortlist of preferences such as this.

@MrAlex94
Copy link
Collaborator

MrAlex94 commented May 15, 2018 via email

@grahamperrin
Copy link
Author

From the POV of me troubleshooting other users' problems: I prefer caution.

Strictly, a refresh – as part of a troubleshooting routine – should unambiguously decrease the risk of problems.

For myself (YMMV) I have barely touched upon extensions that require Firefox 60 or greater. Touch wood, I haven't seen anything that might be troublesome (I see some features of an extension simply not work, but I wouldn't class that as 'trouble'). Fine for me :-) but touching wood, for luck, is not a methodical approach to troubleshooting.

Can we now be certain that all extensions that require, or will require, Firefox 57, 58, 59, 60, 61, 62 … will be non-troublesome with Waterfox 56.2.x? Admittedly I don't know the code etc. but I should err on the side of caution.

(The e10s stuff, too – #397 (comment) – I wince every time I think of someone performing a refresh routine that might worsen the situation.)

@grahamperrin
Copy link
Author

#538

@Peacock365 Peacock365 mentioned this issue May 15, 2018
Closed
51 tasks
@Peacock365
Copy link

Peacock365 commented May 15, 2018 •
edited
Loading

@grahamperrin

Well, you should realize that some extensions might be breaking when you force-enable them, because they might require Firefox 57+ WebExtension APIs that might not be present in Waterfox 56 at all. @Happy-Ferret has offered his help in #389, we could try to come back to this dev.

@grahamperrin
Copy link
Author

grahamperrin commented May 16, 2018 •
edited
Loading

Sorry, my #560 (comment) above was a brain fart. Critically:

  • I forgot that the effect of the boolean is not limited to extensions that are supposedly 'too high' for Waterfox

– there's also the very well established 'power' use case of Waterfox being supposedly too high for some legacy extensions, so (unless I'm having a second bf) false is the sane default.

extensions.checkCompatibility.56.2 is present and false by default in 56.2.0.7 (56.2.0 build 20180515213058) on FreeBSD-CURRENT, so I guess that this issue can close after 56.2.0 goes to general release for other platforms.

grahamperrin referenced this issue May 17, 2018
Update compatibility check.
4368983
@grahamperrin
Copy link
Author

From https://www.reddit.com/comments/8k48rk/-/dz50k5m/ three hours ago:

I did commit it, but seems I forgot to sync the final patch before building and releasing everything 🤦‍♂️.

Hey, these things happen :-)

@grahamperrin
Copy link
Author

about:config?filter=extensions.checkCompatibility.56.2

I found extensions.checkCompatibility.56.2 present and false by default following a first run of build 20180515140315 – on an outdated pre-release of High Sierra – that resulted in:

@AncalagonX
Copy link

I upgraded to Waterfox 56.2.0 today, and also finally upgraded my RES (Reddit Enhancement Suite) to the current version released last week. I believe I experienced the same problem the original issue poster had, where RES was spuriously set to "disabled" due to incompatibility. The simple solution posted above by @MrAlex94 worked perfectly for me:

Adding the boolean extensions.checkCompatibility.56.2 and setting it to false fixed this error, and allowed me to enable the current Firefox RES version released last week (actually, as soon as I added that boolean, the RES addon it auto-enabled itself). Thanks for this solution, and thanks for all the hard work from @MrAlex94 and other contributors on these releases!

@MrAlex94
Copy link
Collaborator

I believe this is fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@grahamperrin @MrAlex94 @AncalagonX @Peacock365