WebExtensions manifest file: content_scripts browser.html, bookmarksPanel.html etc. for Firefox Unbranded

RESOLVED WONTFIX

Status

WebExtensions
Untriaged
RESOLVED WONTFIX
a year ago
5 days ago

People

(Reporter: Łukasz, Unassigned)

Tracking

52 Branch

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170302120751

Steps to reproduce:

Customize the browser for yourself.


Actual results:

WebExtensions appears and blocks it.


Expected results:

Understand that well. There are people who want to have every little thing adjusted. Blocking this API causes you to make this absurd. People will start to make Firefox forks, which will be some minor changes! This is what you will get rid of. Can not you see this absurdity?

The only thing that can save us is the Unbranded version that will not block full extensions.

Theoretically you can do:
"Content_scripts": [
{{
"Matches": ["chrome://browser.html", "chrome://bookmarksPanel.html"],
"Js": ["realExtenson.js"]
}
]

Where chrome://browser.html represents the main browser window, chrome://bookmarksPanel.html represents the default (built-in) bookmark panel. The realExtension.js file would have access to the WebExtensions API and to every function, command, or interface that the browser has access to.
Similarly, you could load CSS files.

But from what I know, they are NOT willing to give you such a possibility, because the Firefox user will set up as he installs his extension and it turns out that something has changed. Extensions have nothing to change. : |
Somehow so far they change, and nothing bad happens.
(Reporter)

Updated

a year ago
Summary: Manifest file: content_scripts browser.html, bookmarksPanel.html etc. for Firefox Unbranded → WebExtensions manifest file: content_scripts browser.html, bookmarksPanel.html etc. for Firefox Unbranded

Updated

a year ago
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
This bug report isn't very clearly written but if you're asking to use webextensions to run privileged browser code, that's not technically feasible (never mind the question of whether its a good idea in the first place).
We have projects like webextensions experiments for cases where you want to do go beyond what the existing webextensions apis allow, we'll be communicating more about those as we get closer to the 57 release.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

a year ago
(In reply to Andrew Swan [:aswan] from comment #1)
> This bug report isn't very clearly written but if you're asking to use
> webextensions to run privileged browser code, that's not technically
> feasible (never mind the question of whether its a good idea in the first
> place).
> We have projects like webextensions experiments for cases where you want to
> do go beyond what the existing webextensions apis allow, we'll be
> communicating more about those as we get closer to the 57 release.

No. That's not what I mean ...

In browser window, not in pages... And in chrome://bookmarksPanel.html (Future equivalent of browserPanel.xul).

It's about having the script access ChromeWindow. As far as I know, in the future it will be pure HTML? That's why I wrote chrome://browser.html. It is crucial that there are no artificial restrictions.

I want to access the browser interface elements. But normal, not some limited.
I want to have the same access to browser functions, commands, without the mediation of a special, limited API WebExtensions.
No additional API, just what the browser uses.

Understand that well. There are people who want to have every little thing adjusted. Blocking this API causes you to make this absurd. People will start to make Firefox forks, which will be some minor changes! This is what you will get rid of. Can not you see this absurdity?

You can not delete browser features.

It may be possible for this unmanaged API to be unlocked in Firefox Unbranded. If someone needs it as much as I do, then we will use Firefox Unbranded.
It would also be useful for forks that would include this option even by default.

I hope I understand it a little now, I wrote.
(Reporter)

Comment 3

a year ago
Correction: bookmarksPanel.xul, not browserPane.xul. Sorry.

Updated

5 days ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.