Closed Bug 788535 Opened 12 years ago Closed 11 years ago

bravestman.com

Categories

(Web Compatibility :: Mobile, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: lmandel, Unassigned)

References

()

Details

(Whiteboard: [clientsniff] [contactready] [webkitcss])

As reported in bug 788522, http://www.bravestman.com uses -webkit prefixed CSS properties. I have not yet investigated what properties are in use
Component: Evangelism → Mobile
OS: Mac OS X → Android
Product: Firefox for Android → Tech Evangelism
Hardware: x86 → ARM
Version: Firefox 15 → unspecified
It says "requires Chrome" with a shopping list of features that need support. There is client-side sniffing redirecting to an unsupported page, but even if that's removed all I get is a white page. Needs some further analysis to see if we really lack support for some of the requirements (quite possibly it's just a matter of getting CSS prefixes right for some animation?)
Whiteboard: [clientsniff]
Features that it claims we don't support: "Hardware Accelerated CSS3 Animations", rAF, and inline SVG. In terms of CSS, everything that makes sense has a corresponding -moz- prefix: http://www.bravestman.com/desktop/assets/css/space.css (though they could use a prefixless variant if they wanted to be extra cool). Here's the actual script: https://gist.github.com/miketaylr/6770584/raw/121f5a022c26d5777f61393e40fe7f49b1d76ec6/gistfile1.txt They see "Android" and assume the native android browser.
(Thanks for adding those extra details Mike - should have done so myself ;-))
When you go there with a desktop. You can read http://www.bravestman.com/desktop/ "Requires an phone or a tablet running Android 4 with Chrome or an Apple iPhone or iPad running iOS 5.0" There is also in the left corner: "This is a Mobile Chrome Experiment". Are we sure we want to spend time on this? I have the feeling it will be turned as a WONTFIX. The domain name belongs to Google. It was created on June 2012. Created on..............: 2012-06-14. Expires on..............: 2014-06-14. Record last updated on..: 2013-10-22.
Whiteboard: [clientsniff] → [clientsniff] [contactready] [webkitcss]
Closing after agreement with mike on IRC ;)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
(In reply to Karl Dubost :karlcow from comment #5) > Closing after agreement with mike on IRC ;) I don't understand, this is being closed because it's a Google demo and they're unlikely to fix their unfriendly behaviour? Isn't that the whole point of evangelism bugs? Do you think you could attach some of that IRC conversation so that this closure makes more sense to those that weren't present?
Flags: needinfo?(kdubost)
In general (without knowing what was said on IRC) we want Tech Evangelism efforts to have as much impact on real user experience as possible, which means we should prioritise sites normal users actually use. If this is just some cool demo very few end users will ever happen to see, it will likely be a waste of time to try to contact them - though perhaps a volunteer might come around and try..
Hello Chris, Google Experimental Web sites are like $ORG experimental Web site, they are often set up to show up some edge capabilities of a product. I think we can find quite some sites, webapps which are not compatible with Chrome because they have been put for showing a cool feature just implemented in Firefox. They are being developed by Google or more likely external agencies driven by a Google Marketing team, and they will not survive for a long time. A couple of years. We can try to spend a lot of time trying to get them fixed and got a no answer (been there, done that when we were working at Opera on the same exact issues) or we can focus our energy on solving Web compatibility issues on sites that are not demo but actual products with more impact. There are plenty. Around 370 opened bugs to contact in Tech Evangelism/Mobile. :) If you feel like reopening, you can. It's a choice. Then someone with other priorities might give it a try. Hope it helps understand.
Flags: needinfo?(kdubost)
Just for a little more context, I've worked closely with Google DevRel (Paul Irish specifically) on Chrome (Mobile) experiments sites before with little to no success in getting fixes made. An agency was contracted to develop something timely to a Chrome release or feature. Years later trying to track down a developer (even from within Google) becomes an impossible task. It's similar to trying to get a fix for a microsite that was created for a 2011 Mazda car using some old version of Raphael.js that only supports X, Y, but not Z features of any browser (speaking from a real life example years ago). If we can catch these issues in time we have better hopes of getting fixes. Granted, 1 year old isn't ancient but I think our Google-karma is better spent right now working issues that affect larger properties (e.g., Google Plus menu not working in Fennec). Hope that's helpful. But like Karl said, feel free to reopen and other people can jump in especially if they know people who might be able to evangelize this site directly. :)
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.