1414078 - Provide API to get and set override navigator properties

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P5)

Description

[Reşat SABIQ (Reshat)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

Without ability to get and set the following and 4 other related preferences, my Blend In extension loses most of its functionality if i convert it to WebExtension:
useragent.override


Actual results:

It will end up spoofing only HTTP User-Agent header (to say it's Windows, etc.), while all the navigator properties will be saying it's Linux, for instance.

Comment 4

[Reşat SABIQ (Reshat)]

If we treat several prefs together in one bug, then the following are the preferences in question (under "general." branch):
"appversion.override", "oscpu.override", "platform.override", "useragent.override", "buildID.override"
These correspond to:
navigator.appVersion, navigator.oscpu, navigator.platform, navigator.userAgent, navigator.buildID

The last is also in scope here until bug 583181 is resolved.

P.S. My extension both gets and sets the overrides, so i hope there would be an API to both get and set. Getting an override pref is not the same as reading a navigator.* property, because it provides additional info: that an override has been set (by the user), which otherwise will not be known.

Comment 5

[sgl4kn]

All those also relate to all User-Agent switchers like Random Agent Spoofer that also needs "network.http.referer.XOriginPolicy"

Comment 6

[Caitlin Neiman [:caitmuenster]]

Hi Resat, this has been added to the agenda for the WebExtensions APIs triage on April 17, 2018. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1A7lwSkunTIdPE8FGqYV93oO-2l8xo3GFqTbY1l1QC1w/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 7

[Kris Maglione [:kmag]]

This can be done with content scripts. so we don't see the need for an additional API.

Comment 8

[Reşat SABIQ (Reshat)]

Thoughts on why it's addressing:
1. Feasibility of certain functionalities:
Without addressing this some things may not be doable.
2. Ease vs. difficult:
Without addressing this some things may be difficult to do.
3. Performance:
Without addressing this, some things may perform slower in comparison to if this is taken care of (in a way similar to how it used to be performance-wise). For instance, before it was a 1-time thing, whereas without addressing this some things may have to be done on a per-page basis.

Comment 9

[Reşat SABIQ (Reshat)]

4. AMO:
Some things could be judged by AMO as not a best practice & thus disallowed. No such concerns will exist if this is addressed.

Comment 10

[Reşat SABIQ (Reshat)]

(In reply to Reşat SABIQ (Reshat) from comment #8)
> Thoughts on why it's addressing:
I meant:
Thoughts on why worth it's addressing:

Comment 11

[Kris Maglione [:kmag]]

Do not re-open bugs or change design decisions after they've been made. If you disagree, feel free to say so in a comment.

Content scripts are relatively cheap and easy to implement, and are perfectly capable of handling this feature. At this point, we don't see the need for an additional API for it.

Comment 12

[Reşat SABIQ (Reshat)]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #11)
> Do not re-open bugs or change design decisions after they've been made. If
> you disagree, feel free to say so in a comment.
There was a race condition, & that's how bugzilla handled my request to post my comment.
> Content scripts are relatively cheap and easy to implement, and are
> perfectly capable of handling this feature. At this point, we don't see the
> need for an additional API for it.
If i encounter any issues on AMO related to content-scripts-based work-arounds, i will refer here saying no other option has been left to implement the desired features. 

P.S. Of course, given the circumstances AMO reviewers should be (informed to be) flexible while reviewing addons employing such work-arounds to implement the needed features.

Comment 13

[Reşat SABIQ (Reshat)]

(In reply to Reşat SABIQ (Reshat) from comment #8)
> Thoughts on why it's addressing:
Of course, I meant:
Thoughts on why it's worth addressing: