Closed Bug 821000 Opened 12 years ago Closed 12 years ago

User-Agent string for B2G desktop doesn't match the UA string for the device

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g18 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
b2g18 --- fixed

People

(Reporter: briansmith, Assigned: briansmith)

Details

Attachments

(1 file)

Add "Mobile; " to the B2G desktop user agent (all B2G builds)
1.01 KB, patch
gerv
: review+
cjones
: review+
Details | Diff | Splinter Review 
A recent build of mine results in: "Mozilla/5.0 (rv:20.0) Gecko/20121211 Firefox/20.0". cjones says this should include "Mobile."
This is by design, because sending "Mobile" to sites will trigger brokenness for desktop builds like pages expecting touch event support.

But you're obviously seeing opposite brokenness.  It would be nice to get a marketplace fix, but the easiest thing to do for now is probably override the UA with a pref.

I agree that this should be more easily enable-able.
I think having B2G Desktop using a different UA from real B2G is just going to cause confusion for people who are using Desktop to test sites because they don't have access to a real device. (And we hope to have a lot of such people.) Particularly as most of them probably don't know about this difference - I certainly didn't!

If B2G desktop is a testing ground rather than a shipping product, then surely maximising site unbrokenness is less important than fidelity to the product we are testing? I suggest the best fix for the problem is for it to have better touch event emulation, even if the UI for it has to be a bit clunky...

Gerv
We are promoting B2G desktop as a dev environment for mobile apps. We need the environment to mimic the on device environment as much as possible. As far as I'm concerned, the UA MUST match in all B2G builds.

Noming for bb with the expectation that this will be marked as a soft blocker that can be fixed after we complete the device work.
blocking-basecamp: --- → ?
(In reply to Lawrence Mandel [:lmandel] from comment #3)
> We are promoting B2G desktop as a dev environment for mobile apps. We need
> the environment to mimic the on device environment as much as possible. As
> far as I'm concerned, the UA MUST match in all B2G builds.
> 
> Noming for bb with the expectation that this will be marked as a soft
> blocker that can be fixed after we complete the device work.

I don't think there's any relevance to blocker or soft blocker here - this is referring to a b2g desktop build. And we're completely out of time to be even considering any of those options for a bug such as this - we should be only blocking critical on-device issues now.

Worst case the FF OS simulator probably could work around this anyways, which is what we are encouraging app developers to use. I'd suggest filing an equivalent issue over there.
blocking-basecamp: ? → ---
We have been blocking on B2G desktop issues that have a significant impact on developers. However, I don't know that this qualifies.

As it was explained to me, R2D2B2G is based on the desktop build.
(In reply to Lawrence Mandel [:lmandel] from comment #5)
> We have been blocking on B2G desktop issues that have a significant impact
> on developers. However, I don't know that this qualifies.

Significant impact usually needs to be at a level where it halts development for B2G itself (like the build is busted). This doesn't fall in that category.

> 
> As it was explained to me, R2D2B2G is based on the desktop build.

Yes. Which means we could probably file a feature request to do this. It's what we are encouraging app developers to use.
Putting needsinfo on Myk to see if there's any issue filed about this on the FF OS simulator.
Flags: needinfo?(myk)
I proposed this very change to Fabrice a couple months ago, back when I was first starting to use B2G Desktop in the Simulator, and he responded that the UA string for B2G Desktop is intentionally without "Mobile", both because it would be technically incorrect and because there may be folks using B2G Desktop as an operating environment for desktop apps (as opposed to a testing environment for mobile apps).

That seems theoretical to me, and I think the real and pressing need for a mobile testing environment outweighs it; but I didn't belabor the point, since it's so easy to override the UA string in the Simulator; so I did that instead.

Nevertheless, I would welcome such a change to B2G Desktop proper, as the fewer modifications I have to make to B2G in the Simulator, the better.

But cc:ing Fabrice for his thoughts, as he'll be able to represent his position better than I can.
Flags: needinfo?(myk)
(In reply to Lawrence Mandel [:lmandel] from comment #5)
> We have been blocking on B2G desktop issues that have a significant impact
> on developers. However, I don't know that this qualifies.
> 
> As it was explained to me, R2D2B2G is based on the desktop build.

At least platform developers will be able to work faster, the more they can use B2G desktop to do their work. The Code-build-deploy-test cycle is much faster. AFAICT, this should also be a very simple change to make. Actually, I think it can be done within Gaia by just setting the UA-override pref, since I've been told that I should just add it to custom-prefs.js in Gaia.
I agree that putting Mobile in the UA is much more crucial for app development and that's the main purpose of using B2G desktop right now.

If everyone agrees that we need to use a pref to develop apps locally, can we add something like general.useragent.is_mobile = true?

With that, we at least will not have to bump the Gecko/Firefox version numbers with each new build. Hopefully nothing is sniffing version numbers, but, you know.
Another vote here to make the simulator fully simulate the phone. We probably want to consider audiences broader than ourselves, i.e. not just marketplace. An app developer will want to be able to see *exactly* the same requests to her servers from the simulator as she would see from the actual phones themselves.
(In reply to Ben Adida [:benadida] from comment #12)
> Another vote here to make the simulator fully simulate the phone.

Erm, just to make sure we're all on the same page here: this is already fixed, and it has been for months, in the Firefox OS Simulator.  This bug is about fixing it in B2G Desktop.
I think the same thing applies there
Myk: ahah, thanks for the clarification. Assuming I understand Jonas, I think I agree with him: Firefox OS is Firefox OS, whether it is desktop build or otherwise. If you have to patch this in the simulator, what's the point of the B2G desktop build?
(In reply to Ben Adida [:benadida] from comment #15)
> Myk: ahah, thanks for the clarification. Assuming I understand Jonas, I
> think I agree with him: Firefox OS is Firefox OS, whether it is desktop
> build or otherwise. If you have to patch this in the simulator, what's the
> point of the B2G desktop build?

That's a good question.

B2G Desktop seems to have a few actual audiences, including Gaia developers, Gaia localizers, and third-party app developers (the last of which is the audience that the Simulator is targeting).  And it seems like all of those audiences would want its UA string to include "Mobile", so B2G Desktop is more similar to the *mobile operating environment* in which their Gaia/localizations/apps will be used on mobile devices.

However, as I mentioned in comment 8, Fabrice has previously justified the current UA string to me by positing that there may be an audience of folks using B2G Desktop as a *desktop operating environment*.  If there is such an audience, and if we care more about them than we do about the other audiences, then perhaps the current UA string is preferable.

More than anything, the length of this discussion, and its paucity of clarity, suggests that we lack a Product Owner for B2G Desktop, i.e. someone to decide why we produce B2G Desktop, who for, and thus what it should (and shouldn't) be/do.

Is there someone who owns the software today?  If so, let that person speak!  And either wontfix this bug or say it should be fixed (after which the actual fix will be trivial and can be done by just about anyone).

Otherwise, if there isn't an owner, then we need to solve that problem first.
btw the patch in comment #11 looks like it will fix it, should some product owner decide it to be fixed
Comment on attachment 695057 [details] [diff] [review]
Add "Mobile; " to the B2G desktop user agent (all B2G builds)

Myk seems to have summed it up nicely. But if a product owner for B2G Desktop does not forward, I think logic suggests we make this change, to meet the use cases we know about.

I'm not the right person to r= this patch from a code perspective, but I r= it from a policy perspective.

Gerv
Attachment #695057 - Flags: review?(gerv) → review+
Comment on attachment 695057 [details] [diff] [review]
Add "Mobile; " to the B2G desktop user agent (all B2G builds)

I want to support Fabrice's use case of an actual desktop-oriented "B2G Desktop" but for now, everybody's using B2G desktop as a simulator for the Unagi device to accelerate development, and so that's the use case we should support now. We will have to do additional work to support a desktop-oriented "B2G Desktop" anyway (e.g. change the default size of the window), and it will be easy to improve upon this patch and/or revert it at that time.
Attachment #695057 - Flags: review?(jones.chris.g)
Comment on attachment 695057 [details] [diff] [review]
Add "Mobile; " to the B2G desktop user agent (all B2G builds)

I don't think this is the right direction in the long term, but I agree this makes sense in the short term.
Attachment #695057 - Flags: review?(jones.chris.g) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/c34660d87368
https://hg.mozilla.org/releases/mozilla-b2g18/rev/a2835c040207

Chris, I accidentally this on the b2g18 branch with a=blocking-basecamp along with my other bugs, even though this is not blocking-basecamp+. But, I still think it is good to have it on the branch. Let me know if you want me to back it out.
Obviously I'm too late here, but really I don't see why we do that. We're now saying that a product (b2g) has the same UA in all contexts it can run, which is just not true. Why was the pref override used by the simulator good enough?
(In reply to Fabrice Desré [:fabrice] from comment #22)
> Obviously I'm too late here, but really I don't see why we do that. We're
> now saying that a product (b2g) has the same UA in all contexts it can run,
> which is just not true. Why was the pref override used by the simulator good
> enough?

Because some developers (including me) are not using the simulator, we're just building B2G Desktop. I understand your concerns and they are valid, but for our immediate needs it the right effort:benefit to do it this way. It will be easy to undo when we have time to work on non-mobile B2G.

RESOLVED FIXED since it landed on -inbound and -b2g18 during the work week.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: