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

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Łukasz]

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.

Comment 1

[Andrew Swan [:aswan]]

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.

Comment 2

[Łukasz]

(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.

Comment 3

[Łukasz]

Correction: bookmarksPanel.xul, not browserPane.xul. Sorry.