WebExtension content script not working on mozilla.org sites

RESOLVED WONTFIX

Status

()

Toolkit
WebExtensions: Untriaged
RESOLVED WONTFIX
a year ago
2 months ago

People

(Reporter: noitidart, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

543 bytes, application/x-xpinstall
Details
(Reporter)

Description

a year ago
Created attachment 8800966 [details]
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.
(Reporter)

Updated

a year ago
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
(Reporter)

Comment 1

a year ago
My webext was working fine until Fx50b6. I was fine in Fx50b5.
(Reporter)

Comment 2

a year ago
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
Last Resolved: a year ago
Resolution: --- → WONTFIX
(Reporter)

Comment 4

a year ago
Aw dang. Is there any chance addons.mozilla.org can get whitelisted I was working on a dev tool addon for it.
(Reporter)

Comment 5

a year ago
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.
(Reporter)

Comment 7

a year ago
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!
(Reporter)

Comment 8

a year ago
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.
(Reporter)

Comment 10

a year ago
Oh great news!

Updated

a year ago
Duplicate of this bug: 1312720
Duplicate of this bug: 1313996
Duplicate of this bug: 1314292
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).

Comment 16

a year ago
(In reply to comment #15)
Fwiw, "Access Denied: You are not authorized to access bug 1295324".

Comment 17

a year 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

11 months 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

8 months ago
+1 for comments and recommendations by Rob Wu and erosman

Comment 20

5 months 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

5 months 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.
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.

Comment 25

4 months ago
(In reply to comment #24)
Indeed, this works, thanks.

Comment 26

3 months 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.
Duplicate of this bug: 1415997
Comment hidden (advocacy)
Comment hidden (advocacy)
You need to log in before you can comment on or make changes to this bug.