The changes for FPR11 (December) and FPR12 will be smaller in scope mostly because of the holidays and my parallel work on the POWER9 JIT for Firefox on the Talos II. For the next couple FPRs I'm planning to do more ES6 work (mostly Symbol and whatever else I can shoehorn in) and to enable unique data URI origins, and possibly get requestIdleCallback into a releaseable state. Despite the slower pace, however, we will still be tracking the Firefox release schedule as usual.
Monday, October 22, 2018
TenFourFox FPR10 available
TenFourFox Feature Parity Release 10 final is now available (downloads, hashes, release notes). This version is live now. Other than outstanding security updates, in this version I also retracted the change (by flipping the pref) for unique data URL origins in issue 525 because of some reported add-on incompatibility. I'm looking at a way add-ons can get around this with their existing code for FPR11, but you're warned: many sites rely on this behaviour to reduce their cross-site scriping surface, and we will have to turn it back on sooner or later.
Hi Cameron, thank you for the latest TFF update! I noticed this carousel of photos does not work - please check: https://www.tampabay.com/mugshots/
ReplyDeleteWorked OK with v9 to the best of my knowledge.
Please, actually recheck the site in FPR9. With the smaller scope for FPR updates, it is far more likely (and occurs far more often) that the site changed to introduce a currently unsupported feature than I introduced a bug. Otherwise this just soaks up time on my part trying to find a regression range when there is no range to find.
DeleteIf I change the browser's user agent string to either IE 8 or 11 it works fine for me.
Delete[ChrisTrusch]One difference between the versions served for "IE 8/11" and "everybody else" is that "everybody else" gets script declarations with unique identifiers in the form of
Deletescript type="13daf2f188a5f5fde6e0e683-text/javascript"
instead of
script type="text/javascript"
Right, that's the RocketLoader. That should be covered by what was introduced in FPR9, so there must be something else about the scripts it's loading.
DeleteAnd it turns out the fix was incomplete; see below. A better (and faster) fix will be in FPR11 or see issue 517.
DeleteThis comment has been removed by the author.
ReplyDeletePer your suggestion I tried to load page and have carousel function - here are results:
ReplyDeleteFPR10 - loads page, images appear on carousel, forward and reverse button on carousel do not function.
FPR9 - page loads, no images appear in carousel and all others functions do not work.
FPR8 - page begins to load and then says "connecting" and never shows any of the page elements.
This is not a critical must have and I did not try Raphael's solution which appears to have worked.
Thanks for your prompt reply Cameron!
Thanks for checking. That sounds like the browser is making incremental progress. I'll see what's left to get the other pieces working in the expectation they may fix other sites.
DeleteGood news: turns out the fix for Rocket Loader is incomplete, and a better one will be in FPR11. This fixes the site and the mugshots appear and are scrollable/clickable.
DeleteI think something is wrong with disk caching. It is not being placed in ~/Caches anymore. FoxBoxes seem to go there as usual, but the main browser cache location can't be found even with Terminal find. Tried to see if a new setting browser.cache.disk.parent_directory was in place, but that pref isn't in place. Is this a Memory Leak Danger? I have an Applescript that wipes disk caches after all Firefox processes have ceased (so as to avoid plugging up my SSD with crap, and really want to be able to continue doing so.
ReplyDelete[ChrisTrusch]Works fine for me, it's caching exactly where it's supposed to be. Have you tried a) with a different Firefox user profile, b) with a different OS X user?
DeleteThis comment has been removed by the author.
DeleteHey Chris - it is sometimes working and sometimes not. This session for instance, went right to ~/Library/Caches, but I've had two that didn't. Suspected that maybe Finder just wasn't showing the folder, so did a Terminal sudo find action for "cache2" and "startupCache.4.big" and sure enough they are nowhere to be found, but it did find them for a FoxBox, instance.
DeleteI suspect that the files are getting written to virtual memory when paging gets complicated, and never actually make it to the proper directory. If this is the case, it isn't a worry, but it just didn't used to happen as much.
No, they don't go through virtual memory. If there's the possibility some settings might have been mucked with like the default cache directory, I'd see if a clean profile shows the same problem (as Chris suggests). I don't see anything like that on the test systems.
DeleteWhat's weird is it is about 50/50 in the new version going to normal caches or to /null (unknown). Not sure what's different, but something is. Seems to work fine, and I can't locate the files anywhere on the system when they don't write to the normal location, so must be in vm somewhere.
DeleteThis might be FF specific but if I set DuckDuckGo as the default search engine it gets reverted to Google after a restart. If you hide or even delete every other engine it does this.
ReplyDelete