10 ms·
User agent overrides for top Japanese Sites
- asyncwords 11y agoIt's an unfortunate state of affairs when a modern browser has to spoof another browser just to get the right content. The user agent in Microsoft's new browser does this by default [1][2]. As a user, I'd love to see a day when browsers don't reveal their user agents and web developers rely on feature detection instead. I admit, though, that I haven't fully considered the collateral damage that might come with that. [1]: http://stackoverflow.com/a/31279980 http://stackoverflow.com/a/31279980 [2]: http://blogs.windows.com/msedgedev/2015/06/17/building-a-more-interoperable-web-with-microsoft-edge/ http://blogs.windows.com/msedgedev/2015/06/17/building-a-mor...
- mmaunder 11y agoAgreed re feature detection. This could lead to an uncomfortable world for devs where the UA becomes completely unreliable - may force a migration to feature detection.
- da_chicken 11y agoI've got bad news for you. We've been at this stage for years already. UA strings are already broken beyond repair. http://www.useragentstring.com/pages/Browserlist/ http://www.useragentstring.com/pages/Browserlist/
- codewithcheese 11y agoAlso UA detection can happen before feature detection which is very handy in some cases such as redirection based on device. Feature detection also implies that there is some sort of client that runs the response which is not always the case.
- err4nt 11y agoSniffing User-Agent has been poor practice since 2011 , in favour of feature detection using a library like Modernizr. I used to advocate using something like Modernizr and then writing your code against the results, but now I think an even more straightforward approach is to just do the feature detection you wish to use directly in your code. No sense in loading in a library and testing for things you don't need, still only to have those tests totally decoupled from the parts of your codebase that depend on the feature detection. It makes more sense to do only the feature detection you need right in your codebase adjacent to the code which relies on the results.
- jszymborski 11y agoYou don't have to include the whole library. Modernizr allows you to customize the package to only detect for features you need. While writing your own feature detection is still probably lightweight (although not by much if you customize modernizr correctly), you're not going to get all the edgecases Modernizr will unless you spend A LOT of time on it. http://modernizr.com/download/ http://modernizr.com/download/
- err4nt 11y agoI get the tradeoff, the problem is when you have 90 projects that customize the library for 90 different needs, and then you want to update those libraries. At that point, you've basically made 90 Modernizr forks. Does it make more sense for you to maintain 90 forks of a library whose codebase you aren't developing and try to keep them current, or to bake-in the parts of Modernizr (with its edge-cases included) right into your codebase for each project, and then only have to maintain your own codebase, instead of your codebase + a library fork. If you're using the majority of Modernizr tests it makes sense to use the full library, but for the most part me and the other devs I've talked to usually drop the whole library in for ease of maintenance, but mainly use it for one feature alone: touchscreen detection. Lately I've tried putting some of my HTML on a diet by replacing my need for Modernizr for the purpose of touschreen detection with this snippet: if(('ontouchstart' in window)||(navigator.msMaxTouchPoints>0)){ // code for touchscreens here… } This keeps the test and the result together in the code, and eliminates the need for a library, which can also be an additional single-point-of-failure outside of your control, especially if hosted by a CDN.
- robotfelix 11y agoIt's worth noting that each custom build includes a commented line with a URL to download the latest version with the same custom set of detects. A great timesaver!
- chc 11y agoIf you're "baking in" parts of Modernizr into your codebase, it seems to me you're still maintaining 90 forks, but it's more work and the provenance of the forked code is less clear.
- drzaiusapelord 11y agoYeah, so its going to report as 'Edge 1.0', not match anyone's regex and a "You need IE6 or higher to visit this page" error? User agent sniffing is just a bad practice. Everything about it is a hack. There's no right way to do something wrong.
- joelwilliamson 11y agoIE has spoofed Mozilla browsers since at least IE2. When was the last time you saw a browser that didn't claim to be Mozilla/5.0?
- ChrisGranger 11y agoI didn't think there was a Mozilla browser until after IE4 came out...
- toyg 11y agoBut there was a Mozilla engine, which is what Navigator had in its UA and Explorer spoofed.
- frou_dh 11y agoAlmost daily I have to spoof my User Agent to claim to be an iPad due to sites confidently proclaiming that Flash is """required""" to get at some audio/video content. What do you know, spoof User Agent, and their Flash """requirement""" instantly evaporates. Pet peeve.
- greggman 11y agoUnfortunately for various reason it's often impossible to use feature detection. 2 examples: 1) There's currently no way to reliable check if a browser support device orientation. Maybe because of bugs or incomplete implementations 2) It's impossible to tell when iOS 8.x has added the chrome around the page in landscape removing nearly 1/3rd of the entire view-able area on an iPhone5S.
- realusername 11y agoThere is some other edge cases like this also: the tel: URI protocol and the HTML5 offline cache.
- Zarel 11y agoMy most recent problem unsolvable by feature detection has to do with the HTML5 `dragend` event: https://github.com/Zarel/Pokemon-Showdown-Client/commit/30f2d5649fc4a58732fae1a8749283a72ff0e584 https://github.com/Zarel/Pokemon-Showdown-Client/commit/30f2... In Chrome, event.pageX/pageY refer to the position of the top left corner of the drag-preview-image, relative to the top left corner of the page. In Safari, event.pageX/pageY refer to the position of the mouse curser relative to (0, window.innerHeight * 2 - window.outerHeight), a point slightly above the bottom left corner of the screen. (Neither of these is spec, which as far as I know says that event.pageX/pageY should be the position of the mouse cursor, relative to the top left corner of the page.) I eventually got around it by storing values from the `drop` event, but anyone who needed these values from the `dragend` event would be screwed. My next most recent problem unsolvable by feature detection has to do with HTML5 Notification, whose API was massively changed recently. Attempting to use the new API on old versions of Chrome would cause the render process to crash (not just throw an error you could catch in a try-block, but actually crash like http://i.stack.imgur.com/DjdCX.png http://i.stack.imgur.com/DjdCX.png ). Of course, using the old API on new versions of Chrome would fail silently, so there was zero way to reliably deliver a notification to the latest version of Chrome without crashing older versions or using user agent detection: https://code.google.com/p/chromium/issues/detail?id=139594 https://code.google.com/p/chromium/issues/detail?id=139594
- frandroid 11y agoUnfortunately, browser bugs don't come with self-identification APIs.
- whoopdedo 11y agoUA overrides are enabling the poor web design that necessitates them. If web sites aren't punished for doing the wrong thing they'll keep doing, requiring more overrides, which hides the bugs, etc. Stop this feedback loop. The client is not responsible for the server's bugs.
- deleted 11y ago[deleted]
- miketaylr 11y agoHi, I disagree (not just because I authored the patch linked here). Web sites are never punished. Our users are.
- andreastt 11y agoIf a user has a sub-par experience browsing a website in one browser, she will switch to another and the loss is on the browser vendor’s behalf and not the website’s. The vendor has an obligation to create the best web experience for the user and while it’s certainly a sad state of affairs that not more sites are testing for features rather than the UA string, it’s a sad fact that not all web authors care enough about interoperability to remedy their bad ways.
- MichaelGG 11y agoI guess this then contributes to a feedback loop. People will check their stats, see that Firefox isn't used, and pay less attention. Sucky position to be in.
- jrockway 11y agoThis is certainly unmaintainable. There are two aspects I find especially interesting. The first is how many different ways sites are determining the browser corresponding to the user agent. You know that they're all based on "guess and test": come up with an idea for an if condition, open up the code in the 5 browsers you care about, see if the result works. It almost reminds me of the output from a fuzzer: it's a valid answer, but you can tell a random number generator and a lot of tries is what got you there. The second is how many web developers seem fine writing the same website many times; once for mobile, once for IE, once for Chrome, once for Firefox. I've always taken the approach of doing exactly one site, and using whatever features are available in the worst browser the client wants supported. If extensive workarounds are needed to make the feature work in every browser, I say skip it. (I was always happy with what IE6 could do.) Of course, when I did web development, it was mostly boring corporate applications, not public websites that face pressure from competitors that are willing to write a codebase from scratch for every browser back to NSCA Mosaic. I consider myself very lucky.
- holygoat 11y agoFennec dev here. Figured I'd address some of these comments. UA overrides are not the only tool in our toolbox. They're deployed in concert with outreach from webcompat. UA overrides are a way of breaking a cycle, not preserving it. They make it feasible for Japanese users to use Firefox without manually messing around with UA overrides (e.g., using Phony). And that gives us leverage. And with leverage our excellent webcompat team can get sites to make changes.
- ShaneWilton 11y agoThings like Modernizr and feature detection are great, but I'm excited to see what happens when coeffects [1] have some more research behind them, and end up being supported by a mainstream programming language. The idea is that you're able to encode information about the execution environment into the type system, so that you can do things like write functions that depend on having access to GPS coordinates, or an audio output device, and so on. The theory is that this will make it easier to target a wide variety of platforms, or devices which may restrict access to information through permissions systems, like those offered by Android or iOS. If, at compile time, you know you've handled all of the cases of an environmental constraint either being met, or not being met, then you have a much stronger guarantee that your code isn't going to unexpectedly fail spectacularly on a platform you haven't tested against. [1] http://tomasp.net/blog/2014/why-coeffects-matter/ http://tomasp.net/blog/2014/why-coeffects-matter/
- realusername 11y agoThere is a lot of websites like this unfortunately, Gmail, Google Maps, Youtube, Office 365... Just try to browse a bit with Firefox for Android and you will see...
- tracker1 11y agoI really wish that all phone/tablet/mobile OSes would simply include an X-Screen-Size (Xpx, Xpx, Xcm) and X-Touch-Enabled header. I've used the detectmobilebrowsers.com as a baseline in the past, and only tweaked slightly so that fallbacks with "phone" will be xs (extra small), otherwise common mobile OSes would get "sm" (small), while desktops get "md" (medium) ... if you use adaptive CSS, and JS you can/should of course adapt if the pre-rendered environment doesn't match. There are other modules written to predetermine a lot more, but it's all kind of a bit sad.