Background: Currently, tablet users are hitting the /m site. Now that we have a navigation option for them (Bug 683209), let's serve them the full site, which is a much better content experience on those devices. This bug is opened per Anthony's recommendation in bug 689987 - Figure out the best way to redirect Firefox tablet users. Assigning to Anthony!
Anthony, we would like this in the 4.7 release. If it's not possible, please update in the bug as to why and the steps you will take to get it into X.X release (fill in with the release).
Target Milestone: 4.6 → 4.7
Anthony, still waiting on an update here. Based on today's website call, please include the following: *Release milestone update *steps you are taking to get it into the update *questions you have
Anthony - Please provide an update here.
CCing Matt from the mobile team might be able to help us. Matt: We need to detect server side if a user is using Firefox on a phone or a tablet. I've seen several discussions about the User-Agent but I don't know what is the plan now. Do you have any info? Or someone who can help us?
Target Milestone: 4.9 → 4.7
Depends on: 671634
OS: Mac OS X → Android
Hardware: x86 → ARM
Thanks Matt! Anthony - I'm moving this to next week's release, on 12/13, however if you can implement a solution before then, by all means that would be great. I know there may be some dependencies on the other two bugs linked to this. Either way, let us know your status and if you have any additional questions.
Target Milestone: 4.7 → 4.10
I tried something in r99085 but I get an infinite redirect loop. It looks like prefetch.php does not receive the $_GET variables. I'm reverting this in r99144 for today's release. I'll fix that later, I don't think it is crucial for today's release (it's only affecting people that already have Firefox) and I prefer to play it safe.
(In reply to Anthony Ricaud (:rik) from comment #7) > I tried something in r99085 but I get an infinite redirect loop. > > It looks like prefetch.php does not receive the $_GET variables. I'm > reverting this in r99144 for today's release. > > I'll fix that later, I don't think it is crucial for today's release (it's > only affecting people that already have Firefox) and I prefer to play it > safe. Hey Anthony, can you provide an update on a fix here. Happy New Year!
I'll take a look at it next Monday (16th). Moving to 1.2.
Target Milestone: 1.1 → 1.2
Sorry for the two days slip, I was stuck on lots of small stuff. Tentative fix in r100104. With SOPA blackout going on today, hard to fully test. Let's check tomorrow.
(In reply to Anthony Ricaud (:rik) from comment #10) > Sorry for the two days slip, I was stuck on lots of small stuff. > > Tentative fix in r100104. With SOPA blackout going on today, hard to fully > test. Let's check tomorrow. Anthony, thanks for the update, sounds like a good plan to me!
Testing on my side looks good.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: r=100104 b=trunk
Target Milestone: 1.2 → 1.3
qa-verified-trunk using stock android browser and Firefox Mobile Nightly 12.0a1
pushed to production r100343
verified fixed http://www.mozilla.org/en-US/firefox/new/ using stock android browser and Firefox Mobile 12.0a1
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.