Closed Bug 1310082 Opened 8 years ago Closed 8 years ago

WebExtension content script not working on mozilla.org sites

Categories

(WebExtensions :: Untriaged, defect)

Product:
WebExtensions
Component:
Untriaged
Version:
50 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: noitidart, Unassigned)

References

Details

Attachments

(1 file)

rawrrawr.xpi
543 bytes, application/x-xpinstall
Details
Attached file rawrrawr.xpi — 
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.
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.
Oops, I meant reviewer* tool. Not dev tool.
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?
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.
Oh great news!
Would it be possible for addons.mozilla.org to log a more helpful message about this?
(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).
(In reply to comment #15)
Fwiw, "Access Denied: You are not authorized to access bug 1295324".
(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.
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.
+1 for comments and recommendations by Rob Wu and erosman
+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)
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.
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.
(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.
Since Firefox 57, we can work around the problem by setting the "privacy.resistFingerprinting.block_mozAddonManager" pref to true.
(In reply to comment #24)
Indeed, this works, thanks.
(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.
(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?
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)
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.
Thanks Kris. I understand. In my case, the reason for needing it is outlined at bug 1416215
Product: Toolkit → WebExtensions
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.

Attachment

General

Creator:
Created:
Updated:
Size: