Closed Bug 1522237 Opened 2 years ago Closed 2 years ago

Disable theme button missing on Nightly 66/Beta 65

Categories

(Toolkit :: Add-ons Manager, defect, P2)

66 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- fixed

People

(Reporter: haik, Assigned: aswan)

References

Details

(Keywords: regression, Whiteboard: [testday-20190412] )

Attachments

(2 files)

After installing a theme such as commando_fox[1], the about:addons theme section no longer includes an option to disable the theme, only the "Remove" button to uninstall the theme.

Reproduced on the problem Nightly 66 and Beta 65 on Mac.

mozregression led me to Bug 857456 - stop supporting install.rdf

  1. https://addons.mozilla.org/en-US/firefox/addon/commando_fox/
Blocks: 857456
Flags: needinfo?(aswan)
Component: Theme → Add-ons Manager
Product: Firefox → Toolkit

For some reason this.hasPermission("disable") [1] is false for enabled static themes. So I guess enabled static themes don't get AddonManager.PERM_CAN_DISABLE for some reason.

[1] https://searchfox.org/mozilla-central/rev/39265dd58298c40bed029617ad408bf806cce761/toolkit/mozapps/extensions/content/extensions.xml#1127

xpi themes never got PERM_CAN_DISABLE:
https://searchfox.org/mozilla-central/rev/5c8ea961d04767db723a0a15e3a8f7fbca154129/toolkit/mozapps/extensions/internal/XPIDatabase.jsm#603

Maybe this is a holdover from the old days when xpi themes were heavyweight themes that required a restart?

The bisection mentioned above doesn't make much sense to me since this logic has existed for a very long time and was not changed in that bug. Note though that as this bug was being filed, lightweight themes were being converted to xpi themes on AMO:
https://mail.mozilla.org/pipermail/dev-addons/2019-January/004041.html
I suspect that the reporter got an update in the midst of trying to bisect and that if you went back to an old (pre-857456) build and installed this theme into a new profile, the issue would still be present.

But in any case, I just took out the (type == "theme") clause and everything seems to work fine, lets give this a try.

Flags: needinfo?(aswan)
Priority: -- → P2

This bug is a regression but was not marked as such. Prioritized as a P2 during the 66 cycle, has a patch attached but no review request and is unassigned. David can we get this bug retriaged? Thanks

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(ddurst)
Keywords: regression
Flags: needinfo?(ddurst) → needinfo?(aswan)
Pushed by aswan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3903ec67f703
Allow xpi themes to be disabled r=rpl
Flags: needinfo?(aswan)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

ni? for uplift

Flags: needinfo?(aswan)

(In reply to Tim Nguyen :ntim from comment #7)

ni? for uplift

Hm, this is already in 67 and 68 and 66 is about to ship so I don't think we're going to make 66.0 so the best we can do is to nominate it for uplift so it can ride along if there's a dot release.

Too late for 66 but do let me know if you think it is impactful enough on users to make it into a 66 dot release.

Thinking about this some more, I don't think the impact is high enough to justify uplift. Pressing the disable button is the same as pressing "enable" on the default theme. If a user doesn't look a particular theme, they can uninstall it or just enable a different one.

Flags: needinfo?(aswan)
QA Whiteboard: [good first verify]

I have reproduced this bug with Nightly 67.0a1 (2019-02-24) on Windows 7, 64 Bit. The fix of this bug is verified with latest Beta 67.0b10.

Build ID : 20190411084603
User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Whiteboard: [testday-20190412]
You need to log in before you can comment on or make changes to this bug.