NotHereToPlayGames

I definitely don't doubt that. Technically, I have ZERO use for St52 outside of one and only one tab (text messages throughout the day). NONE of Roytam's offerings outperform 360Chrome - be it my real use cases or be it artificial benchmarks, they both walk hand in hand here, I've never witnessed real use cases indicate anything different than artificial benchmarks.

Of course it does! "It's all relative." And you can not compare REAL v86 to backport v86 in XP, now can you? Backport v86 is "faster" than REAL v86 in Win10 and in Win7 - my point was that you cannot blanket-statement backports as "inefficient". Inefficient is another way of saying "slower". One of the laptops is triple-boot - XP, 7, and 10. Backport v86 on same hardware and on same network is FASTER than real v86. But no, you cannot test real v86 in XP, we all already know that. Feel free to test on your hardware, backported v86 is FASTER than real v86 - and I'm quite confident that it is for everyone, "not just me".. On XP x64 - Backport v86 scores 75.04. Serpent 52 scores 36.5. New Moon 28 scores 37.7. Next I suppose you'll probably want to see "real" Firefox 52 and "real" Firefox 28 - but I don't have them and I leave that to those that are interested in the results.

Please show that address resolving in any other browser - ie, prove that you don't have access to Google blocked globally. Disable any and ALL antivirus and firewall and "security" programs to at least rule them out.

For one, type a REAL address into the address bar. Typing these FAKE addresses (here and Humming Owl thread) into the address bar is almost like you WANT the browser to "not work".

YES.

YES, it works on XP x64. You have done something wrong as you can't get this or Humming Owl's versions to work.

Since this thread has been revived and I missed it the first time around. I use the below to prevent custom search engines from being added - // ==UserScript== // @name - Disable OpenSearch // @version 2.0.1 // @include http*://* // @run-at document-start // ==/UserScript== //document.querySelector('[type="application/opensearchdescription+xml"]').remove(); ////////////////////////////////////////////////////////////////////////////// // Code from https://github.com/gregsadetsky/chrome-dont-add-custom-search-engines/blob/master/src/content.js // OpenSearch - e.g., https://martin-thoma.com/search-engine-autodiscovery/ // Uses CSS4 selectors, Chrome 49+ const DEBUG=false; let numseen=0, numspoiled=0; let unspoiled=[]; // called when the user clicks an element of the form (any field or button). // The parameter passed is the event object. function clickApply(e) { if(DEBUG) console.info({'form onclick':e}); // remove onclick. One fix only e.srcElement.form.removeEventListener("click", clickApply); applyFix(e.srcElement.form); } //clickApply // add a new <textarea> element function applyFix(elem) { var newelem = document.createElement('textarea'); newelem.name = ''; newelem.style.display='none'; elem.appendChild(newelem); } //applyFix // Add an extra child input to any form that only has one function spoilFormGet(elem) { if(DEBUG) { ++numseen; unspoiled.push(elem); } // Check whether the form submits to a HTTP(S) URL. // A missing or relative action will be resolved against the page URL // so it must have the same URI scheme which is all we care about var action = elem.getAttribute('action'); if(!(action && action.indexOf('://') >= 0)) action = location.href; if(!/^https?:\/\//i.test(action)) return; // Autodetection requires exactly one input of type text or search // If the type attribute is missing, it defaults to `text` // Readonly inputs do not count against this total if(elem.querySelectorAll(':scope input:-webkit-any([type="text" i],[type="search" i],[type*="search" i],[type=""],:not([type])):not([readonly])[name]:not([name=""])').length !== 1) return; // Autodetection also requires no password, file, or textarea elements if(elem.querySelector(':scope :-webkit-any(input[type="password" i],input[type="file" i],textarea)')) return; // Add a <textarea> - unlike <input>, it doesn't block implicit submission // per https://www.tjvantoll.com/2013/01/01/enter-should-submit-forms-stop-messing-with-that/ // apply the fix now, or place it in onclick. "this" is a parameter passed by foreach(). see below if (this.now === true) { // remove onclick placed during first pass elem.removeEventListener("click", clickApply); // and instead do it now; applyFix(elem); } else { elem.addEventListener('click', clickApply); } if(DEBUG) { console.info({Spoiled: elem}); ++numspoiled; unspoiled.pop(); } } //spoilFormGet var debugAutoDetect=0; // move this part of the code here, since it's called multiple times function autoDetect(now, when_called) { if(DEBUG) console.log('autoDetect: '+(++debugAutoDetect)+' ('+when_called+')'); document.querySelectorAll('form:-webkit-any([method="get" i],:not([method]))').forEach(spoilFormGet,{now}); if(DEBUG) { console.log(`Spoiled ${numspoiled}/${numseen}.`+(unspoiled.length?' Unspoiled were:':'') ); if (unspoiled.length) console.log(unspoiled); } // we reset spoil vars for next call numseen=0; numspoiled=0; unspoiled=[]; } //autoDetect function catchOpenSearch() { if(DEBUG) console.info('catchOpenSearch called'); // OpenSearch - e.g., https://martin-thoma.com/search-engine-autodiscovery/ // Uses CSS4 selectors, Chrome 49+ document.querySelectorAll('[type="application/opensearchdescription+xml" i]').forEach( function (it) { it.removeAttribute('type'); if(DEBUG) console.info({"Spoiled by type removal": it}); } ); // Suggestion service, https://www.chromium.org/tab-to-search document.querySelectorAll('url[rel="suggestions" i]').forEach( function (it) { it.removeAttribute('rel'); if(DEBUG) console.info({"Spoiled by rel removal": it}); } ); // added document.querySelectorAll('url[rel="search" i]').forEach( function (it) { it.removeAttribute('rel'); if(DEBUG) console.info({"Spoiled by rel removal": it}); } ); } //catchOpenSearch function onDOMContentLoaded() { if(DEBUG) console.log('onDOMContentLoaded'); catchOpenSearch(); // #1 call it now (i.e., DOMContentLoaded) without applying the fix // #2 call it in 1500 ms and apply the fix // #3 call when document loaded, and apply the fix. // if <form> is added/modified // dynamically before the document // is fully loaded, #1 could miss it, but not #2 & #3. Note that #2 // could fire after #3 if the page is fast to load. Once the fix // is applied, the <form> can't be found by subsequent execution // of autoDetect, so the fix can only be applied once (#1 is not // applied but delayed until #2 or #3 fires, or if the user // clicks). window.addEventListener('load', function() { if(DEBUG) console.log('onload'); catchOpenSearch(); autoDetect(true,'Load'); } ); // #3 setTimeout(function() { autoDetect(true,'Timer'); } ,1500); // #2 autoDetect(false,'onClick'); // #1 } //onDOMContentLoaded (function() { document.addEventListener('DOMContentLoaded', onDOMContentLoaded); onDOMContentLoaded(); })();

I technically don't define it as "based on" anything. It's more of a hodge-podge conglamerate. Theoretically, yeah, I suppose it "started" with Fx52. But... St52 can do nullish coalescing operator, something Firefox couldn't do until v72 - https://caniuse.com/?search=nullish St52 can do optional chaining, something Firefox couldn't do until v74 - https://caniuse.com/?search=chaining St52 partially supports BigInt, something Firefox couldn't do until v68 - https://caniuse.com/?search=bigint The list is kind of endless. BUT there are also things that Firefox can do that St52 cannot do. And even more things that a Chrome-based can do that a Firefox-based cannot do. And vice versa, of course.

Agreed! Though I wouldn't call it all "inefficiencies". Not everyone here is a fan of Speedometer, but one must use some metric that is quantifiable and repeatable - for me, that's Speedometer. As a disclaimer, I am new to using St52 and I picked an older version for my own reasons, newer versions may score higher (but my experience is that they all fall within 5 to 10 points of each other). While 360Chrome v13.5 is a "backport" v86, it scores higher than "real" v86 (on my system, for other systems "mileage may vary"). Ungoogled v113 scores 320! "Real" v86 scores 149. "Backport" v86 scores 166. Serpent 52 scores an abysmal 62.6.

Technically, none of the 360Chrome versions are being "maintained". They have all hit FINAL release stage. Humming Owl no longer updates his versions and is much less of an active member as he once was, but he still does visit on occasion:

And you wonder why I just resort to the "plain" MSFN attachment method. It's easier than having to jump through image-hoster hoops. And I'm a "here and now" person that doesn't care if a future reader cannot follow, "not my problem", lol. <insert Astro's "to each their own" image but too lazy to fetch the URL>

I think he was only pointing out that your linked images do not show in his brower setup. I have witnessed that in the past also, I'd have to spend too much time to hunt it down and what MSFN Member's post it was. If I recall, the image hosting site had a double-extension, call it image.jpg.jpg, so MSFN showed it as a DEAD image. But you could still get access to the image via Dev Tools or also use Dev Tools to edit the HTML and correct the double-extension. edit: I was typing my reply while he was already replying.

yeah, a major nuisance and one of the reasons my "old posts" will show DEAD images.

I discovered the fix by using my standard Proxomitron debugging schemes. But once I found the fix to be a simple css element "unset", I resorted to good ol' old-fashioned custom style sheet inserted by good ol' old-fashioned Stylus. Certainly nothing to warrant dumping v86 in favor of v87. Not for two web sites I'll never visit outside of this discussion.

Correction - I see the issue. My setup is "unsetting" some of the position: absolute's and that fixes the overlaps and also restores "missing" images. I didn't need to "fix" any CSS Reset, I only "unset" <picture> elements' position: absolute.

Do you have to be logged in? Everything looks fine for me while I browse through several items. No text-image overlaps. Everything looks fine. I am on Win7 Enterprise at the moment, but am on 360Chrome v13.5.2036 - only browser on this laptop.

I don't recall, to be honest. I didn't try on a non-server OS at the time. But I don't really recall the server OS really "doing" anything that non-server OS was capable of.

Working for me. But a d@mn annoying web site, if you ask me! Page transitions that remind me of the days that web designers thought <marquee> was cool - it wasn't!

I'm not a Facebook user so can only guess. Based on your screencap versus Dave's screencap, what happens if you click the blue-circle "f" in the upper left corner? It looks like Dave's is "expanded" and yours is "collapsed".

What are your "common denominators"? uBO? Hosts file? Antivirus program? Firewall settings?

I'm talking strictly XP and I think my 36 and 6 "guesses" are actually TOO HIGH of an estimate. What numbers would you put it at?

Thanks indeed. We do have some very helpful members here at MSFN that spend a great deal of time in assisting with enquiries. Unfortunately, we also have a growingly large number of members that will call those helpful posts long-winded or refer to them as A4. Guess we just have to take the good with the bad and learn to live and let live. Or something like that...

Perhaps you over-estimate the intersection. Facebook Users = 2.9 Billion MSFN Members = roughly 36 360Chrome Users = roughly 6

And what a nightmare IMDB is when you allow advertisements! Holy Crap, I was having flashbacks of the days when you opened a web page and 5 pop-ups and 20 pop-unders hit the screen!

I have non-uBO ad-blocks and IMDB loads within 4 seconds when they're enabled. The only way for me to perform a true apples-to-apples comparison for Kafan is to compare out-of-the-box Kafan with out-of-the-box 360Chrome. No extensions (except Page Load Timer) that would tilt either one in their favor. Wouldn't have been "fair" for me to report that IMDB took 40 seconds in Kafan but only 4 seconds in my non-uBO ad-block'd 360Chrome. I also "refuse" to run any browser other than the ones that I personally tweak on my host OS. So the above comparison is Kafan and 360Chrome ran within a 2MB RAM XP VM.