| |||||||||||||
Thunderbird tooThunderbird tooPosted Nov 8, 2011 23:50 UTC (Tue) by raven667 (subscriber, #5198)In reply to: Thunderbird too by rahvin Parent article: Firefox 8 released
It't not version numbers in the traditional sense its a release number. It started with release 4 and now we are at release 8. It's intended to be a reflection of the robustness of the update infrastructure such that one only needs to run "Firefox" and not care about the version, in exactly the same way that people run "Chrome" and don't really care what version they are running as long as it is the latest.
(Log in to post comments)
Thunderbird too Posted Nov 9, 2011 0:12 UTC (Wed) by RCL (guest, #63264) [Link]
Well, we actually do. E.g. NaCl requires at least Chrome 15.
But features of that scale are rare in modern browsers. That is why the perceived ability to get rid of version numbers, because "releases" don't bring a lot more than "twitter searches" and similar stuff that might have been implemented in an addon.
Browser versions will reappear, when
a) major progress restarts in that area and third parties will need to target specific versions, not being able to catch up with pace of development
or
b) "Firefox"-no-name brand gets old and someone will come up with "Firefox II" (or FireAsaDotzler, or whatever) to "refresh" the franchise.
Actually that's the reason... Posted Nov 9, 2011 8:17 UTC (Wed) by khim (subscriber, #9252) [Link] major progress restarts in that area and third parties will need to target specific versions They need this now - this is exactly why version numbers are incremented regularly. For example you mentioned NaCl. Well, NaCl was introduced in Chrome 14, but if you need glibc then it's at least Chrome 15, if you want to use in-browser fonts from NaCl then it's Chrome 16 and if you need mouse capture then you are stuck with Chrome 17, etc. And while changes itself may be small (as you can guess NaCl was much harder to create then mouse capture) psychology matters. If you create something which needs at least Firefox 3.4.5 then you'll hear a lot of complains that your app or website does not work in 3.4.3 with a justification that "it's the same version, it should work", but version 104 vs version 105 are still perceived as "may be different, I need to wait or upgrade".
Actually that's the reason... Posted Nov 9, 2011 15:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> if you need mouse capture then you are stuck with Chrome 17
Mind linking to the relevant docs on this? I don't want sites grabbing my mouse unless explicitly given permission. If authorization isn't needed, I guess it's one more thing to disable in my webkitgtk builds...
No problem... Posted Nov 9, 2011 16:09 UTC (Wed) by khim (subscriber, #9252) [Link] Sorry, I messed up. I meant mouse lock, not mouse capture. Here is the doc. If I remember correctly you must allow it explicitly every time website asks for it, but Chrome team thinks how to make it less tedious (probably some kind of "sticky acceptance"). A lot of games (both HTML5 and NaCl) want mouse lock, thus I'm not sure it's good idea to disable it (although you may not care about games).
No problem... Posted Nov 9, 2011 16:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
I don't particularly care about games. That pretty much leaves just malicious use of it for me. I'm also unsure of how it would work with a modal browser.
The fancy things that are done in HTML5 aren't that spectacular to me which is why I build my own webkitgtk with most of it disabled. Some things just don't need to happen at all. For example, Engine Yard[1] spikes a CPU after a few focus events on it so that it can waste time and energy animating a silly island or whatever making the site basically useless (though I don't do Ruby at all, if any site I *did* use ended up doing something like that, it's an easy way to get me to search for something else).
It's your choice, of course... Posted Nov 9, 2011 16:48 UTC (Wed) by khim (subscriber, #9252) [Link] The fancy things that are done in HTML5 aren't that spectacular to me Well, HTML5 is mostly about webapps these times and if you don't want and don't need webapps - it's your choice, but then it should not matter to you if someone checks version string or UA of browser, or whatever. though I don't do Ruby at all, if any site I *did* use ended up doing something like that, it's an easy way to get me to search for something else. It's your choice. Thankfully few users feel like this so they can usually be ignore. BTW I've checked the Engine Yard: yeah, what it does is completely unnecessary but it does not waste all that many resources and does not waste any when you switch to the other tab so I'm not sure I want to start some kind of jihad which will waste a lot of my own human time and energy to save few percents of battery life on my laptop.
It's your choice, of course... Posted Nov 9, 2011 17:03 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> it does not waste all that many resources
Switching focus 4 times incurs a 3 second delay on the whole window (input, clicks, whatever) while the CPU goes to 100% (Core i7@1.8GHz) emptying the event queue (not to mention that the animation doesn't work while the event queue is being processed). More switches seems to be somewhere near quadratic. Luckily I don't do much mousing around, so focus is unlikely to be a trigger (scrolling is usually a heavy hitter when there's a social bar or whatever hanging around).
It's your choice, of course... Posted Nov 9, 2011 17:07 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> Switching focus 4 times incurs a 3 second delay
Shouldn't do the such tests while make -j8 is going. It's closer to 4 times is a 1 second delay, but it's still feels quadratic if it falls behind at all.
This is strage: in my case it only needs few seconds to settle... Posted Nov 9, 2011 17:25 UTC (Wed) by khim (subscriber, #9252) [Link] Well, yes, it's not the best design you can imagine, but I think the idea that you can fix it in browser is wrong: if it bothers you that much then just don't visit the site. You don't try to fix normal programs with SELinux policies, why do you want to try to do that with webapps?
Thunderbird too Posted Nov 9, 2011 0:54 UTC (Wed) by clugstj (subscriber, #4020) [Link]
BS. Compatibility matters! Once you've eliminated the version number as an indicator of compatibility, you make everyone else who wants to integrate w/ your software suffer.
Thunderbird too Posted Nov 9, 2011 3:58 UTC (Wed) by raven667 (subscriber, #5198) [Link]
Of course compatibility matters but I think browsers are converging on a high level of standards compliance such that, in their opinion, major numbers don't mean much. The standards are also becoming more iterative with small steady changes along with browser development.
It's the same kind of change as when kernel development switched to the 2.6 & 3.x model where there aren't seperate "stable" and "dev" major parallel branches like 2.4/2.5
Thunderbird too Posted Nov 9, 2011 15:29 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
I disagree. Now that there aren't version numbers, web developers will have to start testing for feature compatability. This is a strictly better solution than blacklisting browsers other than the big 4 just because of a silly UA string.
This is mainly because I use uzbl and get blacklisted from sites despite using the same backend as Safari and Chrome and partially because I compile my own webkit for it, disabling things like audio, video, geolocation, database support, and mouse grabbing when that comes along.
Actually it becomes easier... Posted Nov 9, 2011 16:32 UTC (Wed) by khim (subscriber, #9252) [Link] Now that there aren't version numbers, web developers will have to start testing for feature compatability. Actually it's much easier to check for a single "version number" rather then try to parse large and complex "version string" thus it'll make life of web developers easier, not harder. because I compile my own webkit for it, disabling things like audio, video, geolocation, database support, and mouse grabbing when that comes along And this is why I think UA check is the only way to go. It's one thing to support few different browsers with a sane set of features, it's another to use application platform which can have important parts just randomly removed. It's the same thing which plagues desktop linux for ages - no need to have another repeat of the same story. It's one thing to cope with deficiencies of some browsers, but to now cope with randomly crippled ones? No, no need to spend time on that. Thankfully solution is simple: This may be not all that friendly to the DIY guys, but at least this way you'll know that you can safely use local storage, for example (all major browsers support it for many years!) and now worry about fallbacks.
Actually it becomes easier... Posted Nov 9, 2011 16:55 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> Actually it's much easier to check for a single "version number" rather then try to parse large and complex "version string" thus it'll make life of web developers easier, not harder.
Wasn't there talk of not sending the version number in UA strings at all?
> And this is why I think UA check is the only way to go. It's one thing to support few different browsers with a sane set of features, it's another to use application platform which can have important parts just randomly removed.
If that's the case, then UA strings need something along the lines of "I'm actually FooBrowser, but you can treat me like Chrome" so that new/other browsers have a *chance* of being recognized in stats. Without this or feature detection, first-party support will be nigh impossible for new/alternate browsers because "no one uses it" when it really just has to masquerade as anything but itself to even work. This is basically vendor lockout and I don't see why it should be accepted here more than anywhere else.
> This may be not all that friendly to the DIY guys, but at least this way you'll know that you can safely use local storage, for example (all major browsers support it for many years!) and now worry about fallbacks.
Good for them. However, until there's support for blacklisting random sites from dropping whatever data they like onto my machine, it gets disabled completely. Sites already have to cope with the chance that cookies don't work and if they encounter that, they put up a page saying "This site needs cookies to do random stuff, unblock us so we can do A, B, and C.", why not do the same with other features?
Actually it becomes easier... Posted Nov 9, 2011 17:16 UTC (Wed) by khim (subscriber, #9252) [Link] Wasn't there talk of not sending the version number in UA strings at all? Who talks about that and where? I've heard some noises from Opera (because it's often forgotten), but so far all browsers report version number. Without this or feature detection, first-party support will be nigh impossible for new/alternate browsers because "no one uses it" when it really just has to masquerade as anything but itself to even work. This mechanism is there: at least MS IE allows you to change to useragent string using registry so sites can not just do strncmp on useragent string. Without this or feature detection, first-party support will be nigh impossible for new/alternate browsers because "no one uses it" when it really just has to masquerade as anything but itself to even work. Sites do tolerate random additions. So this is not a problem. If someone will decide to follow in Google's footsteps (spend few billions of dollars and get new, supported, browser you can control) it'll not be a showstopper. But if you hope for "equal treatment of minors"... sorry, this phantasy was dispelled long ago. Of course to even be considered seriously you must implement all (or at least most) of the features for the "UA-string donor" browser, or else sites will just blacklist you. Sites already have to cope with the chance that cookies don't work and if they encounter that, they put up a page saying "This site needs cookies to do random stuff, unblock us so we can do A, B, and C.", why not do the same with other features? Because cookies were introduced in different era and some of "big four" still gave you a way to disable cookies? Even so: not all sites bother. Lots of them just break in some way: go in endless redirection loop, or send you to the homepage, etc. I'm sure some sites will check features individually, but most sites will just do what they did for years. It's simple and it works "good enough" so why spend time on some pointless idealistic crusade?
Actually it becomes easier... Posted Nov 11, 2011 20:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Seems I got the UA version disappearing mixed up with the About box hiding of the version number.
For my UA, it seems adding uzbl beside X11 for a Firefox UA still works. Still, I'd like if there were a standard way of doing it for statistical collection purposes.
The impetus behind the video and audio feature disabling is that I don't like websites playing media without consent (e.g., it'd damn near impossible to queue up youtube webpages because they all auto-play). Plus, I have tools to download them and watch them in MPlayer where I get keyboard shortcuts, good seeking, and replay-a-week-later-with-no-download. It also allows me to drop gstreamer dependencies. The database blocking is mostly to hamper tracking and geolocation because I don't need my browser to know.
So yes, I realize that the train has left the station on these features being out there, but it doesn't mean that I'm going to allow sites I visit to control my computer without consent. It's silly that websites can play media without asking "Are you already listening to music? On a call? Listening to an audiobook? Watching another video?" and do nothing if so. If/when uzbl exposes the flags for black/whitelisting these things, I'll enable them again in my builds.
|
|||||||||||||