| |||||||||||||
Actually that's the reason...Actually that's the reason...Posted Nov 9, 2011 8:17 UTC (Wed) by khim (subscriber, #9252)In reply to: Thunderbird too by RCL Parent article: Firefox 8 released
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".
(Log in to post comments)
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?
|
|||||||||||||