Closed
Bug 1310082
Opened 8 years ago
Closed 8 years ago
WebExtension content script not working on mozilla.org sites
Categories
(WebExtensions :: Untriaged, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: noitidart, Unassigned)
References
Details
Attachments
(1 file)
543 bytes,
application/x-xpinstall
|
Details |
Using a content_script with <all_urls> or "*://*.mozilla.org/*" ( per - https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/content_scripts ) is not working on any mozilla.org sites. Attached demo xpi.
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
My webext was working fine until Fx50b6. I was fine in Fx50b5.
I should add I also tested in nightly,52.0a1 (2016-10-13) (64-bit), not working there either.
Comment 3•8 years ago
|
||
Content scripts are currently disabled on certain core Mozilla sites for security reasons. However, they're not disabled on all mozilla.org sites, and they work on most.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Aw dang. Is there any chance addons.mozilla.org can get whitelisted I was working on a dev tool addon for it.
Comment 6•8 years ago
|
||
For the moment you'll have to stick to legacy APIs to inject content scripts on AMO. A couple of my add-ons ported to WebExtensions broke as well.
Thanks Jorge for the note, I fixed your AMO Admin Assistant to SDK, just submitted a PR, I badly needed that, can't live without it!
Hey all I ported my AMO specific addons to SDK, however as I have been working I realized some other addons I rely on (highlighting addon, note taking addon, zooming addon) are WebExts. Pretty handicapped here especially. Is this webext-contentscript block on sites set in stone yet? Or is possible that it can change in the future?
Comment 9•8 years ago
|
||
It's possible that in the future WebExtensions will be able to access those sites again. It's just a more difficult thing to implement than the current block.
Reporter | ||
Comment 10•8 years ago
|
||
Oh great news!
Comment 14•8 years ago
|
||
Would it be possible for addons.mozilla.org to log a more helpful message about this?
Comment 15•8 years ago
|
||
(In reply to Will Bamberg [:wbamberg] from comment #14) > Would it be possible for addons.mozilla.org to log a more helpful message > about this? There's a bug filed for that (bug 1295324).
Comment 16•8 years ago
|
||
(In reply to comment #15) Fwiw, "Access Denied: You are not authorized to access bug 1295324".
Comment 17•8 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #9) > It's possible that in the future WebExtensions will be able to access those > sites again. It's just a more difficult thing to implement than the current > block. I don't know the details, but AMO being unavailable to content scripts seems like a good security feature (for good reasons, the Chrome Web Store cannot be scripted either in Chrome). But for power users there should be an option to allow trusted add-ons to run in otherwise blocked pages. In Chrome there is a concept of component extensions, which can run everywhere (even chrome:// pages). Can we have this in Firefox as well? Then the WebExtension would need an extra permission (requiring admin review for approval) and a pref (disabled by default) for it to work.
Comment 18•7 years ago
|
||
There are other issues that are affected by this restriction. Currently, a number of normal chrome APIs are not working or not implemented or implemented differently in WebExtension. For example, Firefox does not support using alert(), confirm(), or prompt() from background pages. Furthermore, Firefox WebExtension doesn't have a Clipboard function and the document.execCommand('copy') must be executed from content script. I have written workarounds for the above issues but they all include tabs.executeScript() which fails on addons.mozilla.org To clarify, these function only need to use the page as a platform to run simple alert, confirm, prompt, clipboard copy; and not to interact with the addons.mozilla.org content.
Comment 19•7 years ago
|
||
+1 for comments and recommendations by Rob Wu and erosman
Comment 20•7 years ago
|
||
+1 with Comment #17 from Rob Wu. Right now it's really frustrating not having mouse gestures addons working on special pages. Workflow is completely ruined as you can't : - do gesture to close tab while page is loading. Same thing with about:blank, about:home, about:newtab - do gesture to go back or go forward while on addons.mozilla.org We really need : - a way to allow trusted add-ons to run on these pages - or at least to authorize the use of basic function which won't affect security : + going back or forward in history should be ok + as should be reloading page or scrolling in them + same goes for closing or duplicating tab (while opening a new one could lure user into a false site)
Comment 21•7 years ago
|
||
A bit off-topic but it could help you with your problem -> if you need just gestures and you are on Windows, you can use StrokeIt or Strokes Plus desktop applications that will work on every page and actually in every desktop application.
Comment 22•7 years ago
|
||
This bug also affect Scroll To Top extension. This extension updated to WebExtensions just now, however this extension does not create an scroll arrow on www.mozilla.org and addons.mozilla.org, bugzilla does not affected.
Comment 23•7 years ago
|
||
(In reply to Krasnaya Ploshchad’ from comment #22) > This bug also affect Scroll To Top extension. This extension updated to > WebExtensions just now, however this extension does not create an scroll > arrow on www.mozilla.org and addons.mozilla.org, bugzilla does not affected. This extension works on www.mozilla.org after I refresh again and again, sorry.
Comment 24•7 years ago
|
||
workaround |
Since Firefox 57, we can work around the problem by setting the "privacy.resistFingerprinting.block_mozAddonManager" pref to true.
Comment 25•7 years ago
|
||
(In reply to comment #24) Indeed, this works, thanks.
Comment 26•7 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #24) > Since Firefox 57, we can work around the problem by setting the > "privacy.resistFingerprinting.block_mozAddonManager" pref to true. Really nice to know, thanks ! :-) It would be nice if it was accessible via the add on manager.
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment 30•6 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #24) > Since Firefox 57, we can work around the problem by setting the > "privacy.resistFingerprinting.block_mozAddonManager" pref to true. I upgraded to 60.0beta3 and found this pref is invalid, what's going on here?
Comment 31•6 years ago
|
||
I have also noticed that the pref no longer works on 60.0a1 (2018-03-11) (64-bit) and had to downgrade to 60.0a1 (2018-02-28) (64-bit)
Comment 32•6 years ago
|
||
workaround |
You'll also need to remove addons.mozilla.org from the extensions.webextensions.restrictedDomains pref now. Please be aware that these workarounds are not officially supported, so be prepared for them to break again in the future.
Comment 33•6 years ago
|
||
Thanks Kris. I understand. In my case, the reason for needing it is outlined at bug 1416215
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Comment 34•6 years ago
|
||
What about getting it to work on about:reader?
You need to log in
before you can comment on or make changes to this bug.
Description
•