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

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: aaronmt, Unassigned)

Tracking

({regression})

Trunk
mozilla21
ARM
Android
regression
Points:
---

Firefox Tracking Flags

(firefox21 affected)

Details

(Reporter)

Description

5 years ago
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
(Reporter)

Updated

5 years ago
status-firefox21: --- → affected
Version: unspecified → Trunk
(Reporter)

Updated

5 years ago
Component: General → Networking: HTTP
Product: Firefox for Android → Core
Target Milestone: --- → mozilla21
(Reporter)

Updated

5 years ago
Summary: Regression: UA now contains the 'linux' token; 'Linux armv7l;' → Regression: Tablet UA now contains the 'linux' token; 'Linux armv7l;'
(Reporter)

Updated

5 years ago
Keywords: regression
Brad: could you fix this, please? :-)

Gerv
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
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.
(Reporter)

Updated

5 years ago
tracking-fennec: --- → ?
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.
Today's Nightly seems to be working correctly. I see "Tablet" again on my Android tablet.
(Reporter)

Comment 6

5 years ago
Confirming too that 02/08 Nightly,  'tablet is restored (Nexus 7/TF201). This is a little ridiculous; any luck bi-secting inbound?
(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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(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.
(Assignee)

Updated

4 years ago
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.