839065 - Regression: Tablet UA now contains the 'linux' token; 'Linux armv7l;'

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Aaron Train [:aaronmt]]

This is a regression from bug 829596.

Tablet user-agent: Mozilla/5.0 (Android; Linux armv7l; rv:21.0) Gecko/21.0 Firefox/21.0

What it should have been: Mozilla/5.0 (Android; Tablet; rv:21.0) Gecko/21.0 Firefox/21.0

Comment 1

[Gervase Markham [:gerv]]

Brad: could you fix this, please? :-)

Gerv

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

on a local build from http://hg.mozilla.org/mozilla-central/rev/beca57e612fd I get:

Mozilla/5.0 (Android; Tablet; rv:21.0) Gecko/21.0 Firefox/21.0

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

also get the same (correct) UA with a local build from the tip of m-c. I don't know what's wrong with nightly.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

I also pull a refresh inbound tree and can't reproduce the issue. I did see the issue with an older inbound tree. I am currently trying to bisect.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Today's Nightly seems to be working correctly. I see "Tablet" again on my Android tablet.

Comment 6

[Aaron Train [:aaronmt]]

Confirming too that 02/08 Nightly,  'tablet is restored (Nexus 7/TF201). This is a little ridiculous; any luck bi-secting inbound?

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Aaron Train [:aaronmt] from comment #6)
> Confirming too that 02/08 Nightly,  'tablet is restored (Nexus 7/TF201).
> This is a little ridiculous; any luck bi-secting inbound?

No luck with a bisect yet. I will try a bit more today.

Comment 8

[Justin Wood (:Callek)]

(In reply to Mark Finkle (:mfinkle) from comment #7)
> (In reply to Aaron Train [:aaronmt] from comment #6)
> > Confirming too that 02/08 Nightly,  'tablet is restored (Nexus 7/TF201).
> > This is a little ridiculous; any luck bi-secting inbound?
> 
> No luck with a bisect yet. I will try a bit more today.

No need to bisect (more).

The issue was that the Nightly for 02/07 was scheduled/built on the parent of the cset of blasseys that landed.

Our nightly scheduling code picks the newest build/cset that was "good" where good is defined as "set of builds we need are not red" (orange is fine) on blassey's push that was a red OSX64 (10.7) debug.

On subsequent (later) builds it was Asan Linux64, which shouldn't get checked [but does atm], we have a bug on file for that: Bug 835173

So long story short, the automation acted as we expect, and there was no code change causing a regression from what blassey pushed, so WFM is a good resolution, and the issue was not with how the nightly was created.