Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Phony type functionality for B2G

109 views
Skip to first unread message

Lawrence Mandel

unread,
Nov 6, 2012, 5:11:40 PM11/6/12
to dev-b2g, compat...@lists.mozilla.org
To support the mobile Web compatibility effort, I would like to add functionality to B2G that allows switching/spoofing the UA. Something like Phony (https://addons.mozilla.org/en-US/mobile/addon/phony/) would work well. AFAIK, the B2G browser does not support add-ons. Is there a way for an app to change the B2G UA? Does anyone have any other ideas for how to easily add this type of functionality to B2G?

Thanks,

Lawrence

Donovan Preston

unread,
Nov 6, 2012, 6:15:25 PM11/6/12
to Lawrence Mandel, compat...@lists.mozilla.org, dev-b2g
You can spoof it right now with a hacky preference. Add the following
to a file custom-prefs.js inside the gaia dir and reflash gaia.

user_pref("general.useragent.override", "[Spoofed UA]");
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g


Gervase Markham

unread,
Nov 7, 2012, 6:21:03 AM11/7/12
to Donovan Preston, Lawrence Mandel
On 06/11/12 23:15, Donovan Preston wrote:
> You can spoof it right now with a hacky preference. Add the following to
> a file custom-prefs.js inside the gaia dir and reflash gaia.
>
> user_pref("general.useragent.override", "[Spoofed UA]");

But B2G doesn't have anything like about:config yet, does it? Are there
any plans to implement something like that?

Having to reflash the entire phone just to test with an alternative User
Agent is not practical.

Gerv


Lawrence Mandel

unread,
Nov 7, 2012, 10:18:14 AM11/7/12
to Donovan Preston, compat...@lists.mozilla.org, dev-b2g
> You can spoof it right now with a hacky preference. Add the following
> to a file custom-prefs.js inside the gaia dir and reflash gaia.
>
> user_pref("general.useragent.override", "[Spoofed UA]");

Thanks for the details. I'm actually looking for a way to do this at runtime. In this context, the test method is:

1. Load site in Firefox and test.
2. Spoof UA to Android phone UA and retest.

Can I change that pref via an app at runtime?

Lawrence

Jason Smith

unread,
Nov 7, 2012, 10:23:22 AM11/7/12
to Lawrence Mandel, Donovan Preston, compat...@lists.mozilla.org, dev-b2g
I know you can change the pref by modifying the profile via adb.

Sincerely,
Jason Smith

Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com
> _______________________________________________
> compatibility mailing list
> compat...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/compatibility

Fabrice Desre

unread,
Nov 7, 2012, 11:39:57 AM11/7/12
to Gervase Markham, Donovan Preston, mozilla...@lists.mozilla.org, Lawrence Mandel
On 11/07/2012 03:21 AM, Gervase Markham wrote:
>
> But B2G doesn't have anything like about:config yet, does it? Are there
> any plans to implement something like that?

There's no about:config and no plans to add a generic one.

> Having to reflash the entire phone just to test with an alternative User
> Agent is not practical.

Fair enough. We could add a setting for that but I fear that people
would abuse the feature and never switch back to the default UA.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

Lucas Adamski

unread,
Nov 7, 2012, 12:31:24 PM11/7/12
to Jason Smith, Donovan Preston, compat...@lists.mozilla.org, Lawrence Mandel, dev-b2g
I've been using this simple script for messing with CSP policies:

adb pull /system/b2g/defaults/pref/user.js
vim user.js
adb shell mount -o rw,remount /system
adb push user.js /system/b2g/defaults/pref/user.js
adb shell mount -o ro,remount /system
adb reboot
sleep 5
adb logcat > temp.log &
tail -f temp.log

The reboot is probably not optimal but better safe than sorry.
Lucas.

Fabrice Desre

unread,
Nov 7, 2012, 12:39:35 PM11/7/12
to Lucas Adamski, Jason Smith, Donovan Preston, compat...@lists.mozilla.org, Lawrence Mandel, dev-b2g
On 11/07/2012 09:31 AM, Lucas Adamski wrote:
> I've been using this simple script for messing with CSP policies:
>
> adb pull /system/b2g/defaults/pref/user.js
> vim user.js
> adb shell mount -o rw,remount /system
> adb push user.js /system/b2g/defaults/pref/user.js
> adb shell mount -o ro,remount /system
> adb reboot
> sleep 5
> adb logcat > temp.log &
> tail -f temp.log
>
> The reboot is probably not optimal but better safe than sorry.

You can use |adb shell stop b2g && adb shell start b2g| instead of
rebooting to just restart gecko.

Gervase Markham

unread,
Nov 8, 2012, 5:42:24 AM11/8/12
to Fabrice Desre, Donovan Preston, Lawrence Mandel
On 07/11/12 16:39, Fabrice Desre wrote:
> On 11/07/2012 03:21 AM, Gervase Markham wrote:
>>
>> But B2G doesn't have anything like about:config yet, does it? Are there
>> any plans to implement something like that?
>
> There's no about:config and no plans to add a generic one.

Wow, that sucks. :-| Is this an explicit policy decision or simply due
to time constraints? There are a massive load of things which can be
configured via prefs which are useful for testing.

Hackability is one of Mozilla's core software strengths.

> Fair enough. We could add a setting for that but I fear that people
> would abuse the feature and never switch back to the default UA.

If we are going to add a setting, I would rather see the time spent
adding a mechanism to add settings for any named pref. Or at least
providing a mechanism to write a trusted app that could do it.

Gerv

Lawrence Mandel

unread,
Nov 8, 2012, 10:36:23 AM11/8/12
to Fabrice Desre, Jason Smith, Donovan Preston, compat...@lists.mozilla.org, dev-b2g, Lucas Adamski
This sounds more reasonable but still a slow path for testing. Any other ideas on how we can modify the UA at runtime?

Do apps have the ability to set system prefs?

Can I dynamically add an entry to the domain whitelist at runtime?

Lawrence

Jonas Sicking

unread,
Nov 9, 2012, 3:50:29 AM11/9/12
to Gervase Markham, Donovan Preston, Fabrice Desre, mozilla...@lists.mozilla.org, Lawrence Mandel
On Thu, Nov 8, 2012 at 2:42 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 07/11/12 16:39, Fabrice Desre wrote:
>>
>> On 11/07/2012 03:21 AM, Gervase Markham wrote:
>>>
>>>
>>> But B2G doesn't have anything like about:config yet, does it? Are there
>>> any plans to implement something like that?
>>
>>
>> There's no about:config and no plans to add a generic one.
>
>
> Wow, that sucks. :-| Is this an explicit policy decision or simply due to
> time constraints? There are a massive load of things which can be configured
> via prefs which are useful for testing.

This is due to time constraints. It's much harder to implement in B2Gs
security model since we essentially don't have any chrome JS code
running other than what's part of gecko. In fact, we don't have any
chrome code which displays UI at all.

> Hackability is one of Mozilla's core software strengths.

I agree. Though it's a bit trickier also since we want to make it hard
to brick your device. With desktop Firefox you can at worst case blow
away your profile. But if your phone isn't starting most people would
be in trouble.

But I agree this is something that we should try to figure out.

/ Jonas

Gervase Markham

unread,
Nov 9, 2012, 8:01:23 AM11/9/12
to mozilla...@lists.mozilla.org
On 09/11/12 08:50, Jonas Sicking wrote:
> This is due to time constraints. It's much harder to implement in B2Gs
> security model since we essentially don't have any chrome JS code
> running other than what's part of gecko. In fact, we don't have any
> chrome code which displays UI at all.

But the settings app allows the changing of things which are prefs
underneath, right?
http://blog.astithas.com/2012/11/javascript-debugging-updates.html
suggests so.

Can't it just grow an extra facility where you input both the pref to
change and the value, instead of just a value? Even that would be a lot
better than having to reflash or reboot.

For bonus points, you could then "save" a pref name with a title, so
there was a screen of prefs that you'd said you wanted UI for - and it
would provide UI according to pref type.

For extra bonus points, remember previously-entered values for Text and
Number prefs and allow choosing between them.

But neither of the bonuses is essential.

> I agree. Though it's a bit trickier also since we want to make it hard
> to brick your device. With desktop Firefox you can at worst case blow
> away your profile. But if your phone isn't starting most people would
> be in trouble.
>
> But I agree this is something that we should try to figure out.

It is impossible to brick an Android device (to a similar degree) via
the UI, even using advanced settings and toggles?

Gerv


Robert Kaiser

unread,
Nov 9, 2012, 8:31:38 AM11/9/12
to mozilla...@lists.mozilla.org
Gervase Markham schrieb:
> On 07/11/12 16:39, Fabrice Desre wrote:
>> On 11/07/2012 03:21 AM, Gervase Markham wrote:
>>>
>>> But B2G doesn't have anything like about:config yet, does it? Are there
>>> any plans to implement something like that?
>>
>> There's no about:config and no plans to add a generic one.
>
> Wow, that sucks. :-| Is this an explicit policy decision or simply due
> to time constraints? There are a massive load of things which can be
> configured via prefs which are useful for testing.
>
> Hackability is one of Mozilla's core software strengths.

There's no about: pages that run in chrome mode at all (which most do),
i.e. no about:config, about:crashes, about:memory, etc. - we cannot run
chrome-privileged pages inside content-privileged apps due to security
reasons. This bites us in multiple case and we can't do a lot about it
(actually, there's work ongoing to re-implement "something like
about:crashes" with various tricks to not require chrome access, but I
consider this quite hackish).
I'm also not sure how we'd ever be able to "fix" that problem, but not
having those pages really cuts into our debugging, testing, and hacking
abilities on Firefox OS, that's right.

Robert Kaiser

Gervase Markham

unread,
Nov 12, 2012, 11:34:37 AM11/12/12
to Robert Kaiser
On 09/11/12 13:31, Robert Kaiser wrote:
> There's no about: pages that run in chrome mode at all (which most do),
> i.e. no about:config, about:crashes, about:memory, etc. - we cannot run
> chrome-privileged pages inside content-privileged apps due to security
> reasons. This bites us in multiple case and we can't do a lot about it
> (actually, there's work ongoing to re-implement "something like
> about:crashes" with various tricks to not require chrome access, but I
> consider this quite hackish).

Can we solve it by creating a separate, trusted app which displays the
data which would be displayed on those pages? Or would there be a
problem with it getting access to it because it's not part of the same app?

Gerv

Jonas Sicking

unread,
Nov 13, 2012, 6:46:07 AM11/13/12
to Gervase Markham, mozilla...@lists.mozilla.org
On Fri, Nov 9, 2012 at 5:01 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 09/11/12 08:50, Jonas Sicking wrote:
>>
>> This is due to time constraints. It's much harder to implement in B2Gs
>> security model since we essentially don't have any chrome JS code
>> running other than what's part of gecko. In fact, we don't have any
>> chrome code which displays UI at all.
>
> But the settings app allows the changing of things which are prefs
> underneath, right?
> http://blog.astithas.com/2012/11/javascript-debugging-updates.html suggests
> so.

Just because the settings app can take some actions which end up
causing some preferences to change, doesn't mean that it can control
all settings.

> Can't it just grow an extra facility where you input both the pref to change
> and the value, instead of just a value? Even that would be a lot better than
> having to reflash or reboot.
>
> For bonus points, you could then "save" a pref name with a title, so there
> was a screen of prefs that you'd said you wanted UI for - and it would
> provide UI according to pref type.
>
> For extra bonus points, remember previously-entered values for Text and
> Number prefs and allow choosing between them.
>
> But neither of the bonuses is essential.

It would indeed be possible to add an API exposed to the settings app
which allowed it to modify arbitrary Gecko preferences. What I was
referring to was running about:config or other chrome-privileged
pages.

However, see below.

>> I agree. Though it's a bit trickier also since we want to make it hard
>> to brick your device. With desktop Firefox you can at worst case blow
>> away your profile. But if your phone isn't starting most people would
>> be in trouble.
>>
>> But I agree this is something that we should try to figure out.
>
> It is impossible to brick an Android device (to a similar degree) via the
> UI, even using advanced settings and toggles?

As far as I know yes.

/ Jonas

Jonas Sicking

unread,
Nov 13, 2012, 6:51:34 AM11/13/12
to Gervase Markham, mozilla...@lists.mozilla.org, Robert Kaiser
On Mon, Nov 12, 2012 at 8:34 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 09/11/12 13:31, Robert Kaiser wrote:
>>
>> There's no about: pages that run in chrome mode at all (which most do),
>> i.e. no about:config, about:crashes, about:memory, etc. - we cannot run
>> chrome-privileged pages inside content-privileged apps due to security
>> reasons. This bites us in multiple case and we can't do a lot about it
>> (actually, there's work ongoing to re-implement "something like
>> about:crashes" with various tricks to not require chrome access, but I
>> consider this quite hackish).
>
> Can we solve it by creating a separate, trusted app which displays the data
> which would be displayed on those pages? Or would there be a problem with it
> getting access to it because it's not part of the same app?

It's software. Anything is possible. However it would take
re-implementing all of the about: pages using the B2G security model
rather than using chrome-privileged code.

I don't think adding the ability to set preferences has the right time
vs. added hackability vs. bricking-risk ratios.

/ Jonas

Gervase Markham

unread,
Nov 14, 2012, 7:07:29 AM11/14/12
to Jonas Sicking
On 13/11/12 11:46, Jonas Sicking wrote:
> It would indeed be possible to add an API exposed to the settings app
> which allowed it to modify arbitrary Gecko preferences. What I was
> referring to was running about:config or other chrome-privileged
> pages.
>
> However, see below.

OK. Could we add such an API, and then have a (regexp-based, perhaps)
whitelist of preferences the app would pass through to be set, or
blacklist of stuff that couldn't be changed?

I'm trying to figure out how we can restore some hackability without
opening the possibility of bricking. Perhaps it's not possible. But
then, if I wanted to destroy my phone, I could drop it in a river. And
if a web page said "to clean your phone, drop it in a river and wait 5
minutes", I'd still be a fool for doing so. How is that different from a
page which says "set the pref which gives the URL to the home screen app
to be http://nonexistent.com"?

Gerv

Gavin Sharp

unread,
Nov 14, 2012, 2:30:37 PM11/14/12
to Gervase Markham, mozilla...@lists.mozilla.org
On Wed, Nov 14, 2012 at 4:07 AM, Gervase Markham <ge...@mozilla.org> wrote:
> And if a web page said "to clean your phone, drop it in a river and wait
> 5 minutes", I'd still be a fool for doing so. How is that different from a
> page which says "set the pref which gives the URL to the home screen
> app to be http://nonexistent.com"?

The implications of the former are much more obvious to a non-technical user.

Gavin

Jonas Sicking

unread,
Nov 15, 2012, 10:28:40 PM11/15/12
to Gervase Markham, mozilla...@lists.mozilla.org
On Nov 14, 2012 4:07 AM, "Gervase Markham" <ge...@mozilla.org> wrote:
>
> On 13/11/12 11:46, Jonas Sicking wrote:
>>
>> It would indeed be possible to add an API exposed to the settings app
>> which allowed it to modify arbitrary Gecko preferences. What I was
>> referring to was running about:config or other chrome-privileged
>> pages.
>>
>> However, see below.
>
>
> OK. Could we add such an API, and then have a (regexp-based, perhaps)
whitelist of preferences the app would pass through to be set, or blacklist
of stuff that couldn't be changed?

I'd say we're already within the realm of things that we don't have time to
do for v1. Especially once you add UI and QA for these features to the
equation.

> I'm trying to figure out how we can restore some hackability without
opening the possibility of bricking.

Hackability is to me quite different from being able to set prefs.

Ability to install custom high privileged apps is IMO much more important
and we already have that.

/ Jonas

Gervase Markham

unread,
Nov 16, 2012, 6:51:30 AM11/16/12
to mozilla...@lists.mozilla.org
On 16/11/12 03:28, Jonas Sicking wrote:
> I'd say we're already within the realm of things that we don't have time to
> do for v1. Especially once you add UI and QA for these features to the
> equation.

Fair enough. Then let's not get distracted from the purpose of this
thread, which is adding Phony-like functionality. That would be a
massive help to the teams tasked with trying to make the mobile web
FirefoxOS-compatible.

Gerv

Lawrence Mandel

unread,
Dec 7, 2012, 4:38:20 PM12/7/12
to Fabrice Desre, Jason Smith, Donovan Preston, compat...@lists.mozilla.org, dev-b2g, Lucas Adamski
> On 11/07/2012 09:31 AM, Lucas Adamski wrote:
> > I've been using this simple script for messing with CSP policies:
> >
> > adb pull /system/b2g/defaults/pref/user.js
> > vim user.js
> > adb shell mount -o rw,remount /system
> > adb push user.js /system/b2g/defaults/pref/user.js
> > adb shell mount -o ro,remount /system
> > adb reboot
> > sleep 5
> > adb logcat > temp.log &
> > tail -f temp.log
> >
> > The reboot is probably not optimal but better safe than sorry.
>
> You can use |adb shell stop b2g && adb shell start b2g| instead of
> rebooting to just restart gecko.
>

Based on these instructions, I have created a script that allows you to easy change the UA from the command line. The script prereqs adb on your path.

https://gist.github.com/4234696

Use the script as follows

./changeUA.sh fennec
./changeUA.sh android
./changeUA.sh

The third command (no option) reverts B2G to the default UA.

Lawrence
0 new messages