For FPR5 the big goals are expanded AltiVec (enable strchr() everywhere else, finish as much as possible of the AltiVec VP9 intra predictors), some DOM and Web compatibility improvements, and some additional performance improvements primarily in the session store module and the refresh driver. More on those soon.
Friday, November 10, 2017
TenFourFox FPR4 available
TenFourFox Feature Parity Release 4 final is now available (downloads, hashes, release notes). It will become live on Monday "evening" as usual. There is no debug version for final since the only reason I was doing that for the last FPR or two was to smoke out issue 72, for which the fix now appears to be sticking (but, as usual, there will be one for FPR5b1).
Subscribe to:
Post Comments (Atom)
CK - have noticed an odd bug since PR where the minimize button stops working when the browser has been left open for a while. Also, there seems to be a common situation where the browser will simply drop javascript-strings and they cease to be functional (even things like buttons) unless the browser is refreshed. Otherwise each new iteration has been noticeable faster than the previous. Am working on a GIANT wordpress site for a customer and last fall doing the same work was painfully slow, but now has been really very fast and responsive.
ReplyDeleteI'll watch for the minimize button issue, though I haven't experienced that myself.
DeleteWhat do you mean by "drop javascript-strings"? Do you have an example site?
It isn't a particular site, it pages just 'deactivate' periodically - and in one tab it will still be fine, where another just becomes totally unresponsive. Is there something in Console I should look for? Happens at least once a day.
DeleteI swear I'm not being deliberately obtuse, but I'm still not understanding exactly what's going on.
DeleteNo problem.
DeleteBasically a page will just quit doing it's thing. Have seen it in several sites. Buttons stop responding, images don't load, but rather than getting a dialog about a javescript running slow or ceasing to respond (with the usual quit or wait options), the page just never comes back.
And other pages (tabs) remain completely fine. Honestly it feels a lot like a timeout on javascript giving up. Not sure if that is present, or if there is something else at work, but it has been steadily happening since we went to feature parity. Have even tried it with a profile with all addons gone and it still happens. None of the usual spinning beach ball or the like, just a 'give up'.
It shouldn't be considered a critical bug, because a page-refresh usually fixes it, but is just weird and maybe something to keep an eye on.
For the Window Minimize bug - that more of a drag because I have to close the entire browser and reopen it to get it working again - I have a theory on this one:
Since I'm on a Sandforce SSD, that will self-trim blocks, it could be that code string that controls window minimize has simply been pushed to swap, and a piece of it might be unavailable with some of the block's contents are being trimmed - have seen this in other apps from time to time, but it too has only cropped up since the FP releases.
NONE of this is a big deal as the browser is kicking butt - but like I say, just something to keep an eye on relating to other more critical bugs.
Hmm, OK. I'm not sure what to say about that and the behaviour doesn't ring any bells, but I'll watch for other reports.
DeleteThis is more out of curiosity but, did you bring any changes to the TFFx source tree that would deliberately break support for linux on big-endian powerpc (apart from the JIT which I'm aware would need changes to use the SysV ABI)?
ReplyDeleteNot directly, although some of the chrome code now assumes the system is always running on OS X for reasons of efficiency. Those changes are marked, so they can be backed out.
Delete