NotHereToPlayGames

I agree! I know! I did not intend to imply that you did! Here, for the sake of an easier-to-follow discussion and a summary of how we got here. Here's how I recall it all unfolding. If I have the chronological order out of place, again, I apologize, but I'm generally pretty good at chronological events. One, there was a discussion between you, me, and perhaps a few others surrounding these embedded extensions and my notes recorded the following (it's in one of the other 360Chrome threads) -- 1 - mhjfbmdgcfjbbpaeojofohoefgiehjai PDF Viewer OFFSET 13022 2 - fjajfjhkeibgmiggdfehjplbhmfkialk CryptoTokenExtension OFFSET 15624 3 - gfdkimpbcpahaombhbimeihdjnejgicl Feedback to Gurgle (!) OFFSET 13882 4 - Chrome Web Store Cloud Print OFFSET 11562 5 - ahjtciijnoiaklcomgnblndopackapon Identity API Scope Approval UI at OFFSET 326728 Two, that discussion turned into me turning to ungoogled-chromium and which of these embedded extensions should remain in 360Chrome because they also remain in ungoogled-chromium. It was at this point where you cited (and I agree, mostly) your stance on ungoogled-chromium. I respect your stance! Three, I did not remove the entire list of discussed embedded extensions, I kept those that ungoogled-chromium has in their code and removed others (our list may be longer, I seem to recall a retired cloudprint one that I removed also). Our discussion, at that time, led me to remove SOME embedded extensions but KEEP other embedded extensions. I seem to recall even seeing that it took longer for 360Chrome to launch without the embedded extensions versus with them. Four, it was around this time that Humming Owl released notes where he removed all references to googleapis in v12. Five, with no adverse side effects from that experiment of removing all references to googleapis in v12, it was either Humming Owl or myself, don't recall in hindsight but it will be in that other thread, that all references of googleapis were removed in v13 - as an experiment. Six, with no adverse side effects reported, that experiment still holds and as of this point both Humming Owl and I have those refences removed in chrome.dll. Seven, discussions regarding registry entries surrounding esent.dll. It was at this point where I suggested to Humming Owl to NOT remove references to esent.dll because ungoogled-chromium has the exact same esent.dll references. To the best of my knowledge, Humming Owl reverted his esent.dll removals, unsure on this. I never removed any esent.dll references in my own build. Eight, several weeks pass and a discussion regarding "connections" when a user compares my build to Humming Owl's build. This is when I discuss the command line startup that would prevent those "connections" on Humming Owl's build. Nine, Humming Owl chimes in and cites he is aware of those "connections" but that he left them intentionally for something called Chromecast. Ten, I cite that Chromecast is likely already broken because of a blanket-removal of all references to googleapis. That's pretty much how I saw it all unfold. I'm on MSFN daily, I doubt that I missed anything.

Consider it this way, a web site called "Greasy Fork" is an excellent source for Greasemonkey / Tampermonkey / Violentmonkey user scripts. It is very common for user scripts to have an @require setting where a googleapis is downloaded ONCE and stored locally for that user script to use over and over and over. The user script only needed to download it ONCE. But if you don't use the @require setting then our web browser now has to download it EVERY time instead of just ONCE. Just thinking out loud - I do have all googleapis references removed in my own build. But I do have to wonder, did I err on the side of safety? Or on the side of breaking things that I just don't know are broken because I haven't tried the right extension or visited the right web site? Or, by removing the googleapis LOCALLY, did I create a web browser that now has to FETCH that googleapis instead? Wouldn't it be better to have it LOCALLY then have to FETCH it every time the web browser / web site needs it? Hhmmm...

Agreed! I kinda pointed this out when we were discussing esent.dll (page 11 of this thread). I really think we can not axe things just for the sake of "warm fuzzies" when we don't know 'everything' that entries like "googleapis" and "esent.dll" really-and-truly DO. I think some peoples' paranoias tend to get ahead of themselves and it becomes very easy to create a "working" browser that has BROKEN FUNCTIONALITIES that only come to the surface months later when testing a new extension. So was that browser really "working" to begin with? I'm exaggerating (slightly). But we really cannot let our paranoias turn 360Chrome into something that is "broken". I like ya @Dixel so I am not casting this net over you (more in a second, we are of the same feather!), though to discuss I do have to bring up something you've said in the past. I once SUGGESTED that some of the googleapis should STAY in 360Chrome BECAUSE they also exist in "ungoogled-chromium". Your reply was something along the lines of disrespect towards the "ungoogled-chromium" project because of their use of the word "ungoogled". But my suggestions remains - we should not be removing something like "googleapis" in the dozens upon dozens of locations where it exists in chrome.dll just for the same of a "warm fuzzy". Although, having said that, and back to my same-feather reference earlier, I do err on the side of caution and I remove all googleapis references in my own rebuild -- but what did I "break" by doing so? Because they were there for a reason and I do not know those reasons. I do know that all of my extensions work, my visited web sites work, et cetera. But rest assured, "something" is BROKEN just by blindly replacing all "googleapis" references without really and truly knowing why they are there. Our collective paranoia might have, just possibly, taken us a wee bit TOO FAR and we might have, just possibly, stripped out more than we "should" have all because we kept looking up in the mirror to see if somebody was following us. If you pay too much attention to that rear view mirror, you will run over a child running into the street. But I digress...

I don't use Chromecast service, so I cannot confirm - but wouldn't this service be broken by the below replacement/modification listed in your v13 build 2250 notes --

I have not verified, but my hunch is that if you launch Humming Owl's with the below command line switch, then his won't connect to Google at launch -- --disable-background-networking

Good catch! I see that now and didn't notice it at first. And something like "gstatic" could easily be a common denominator. My NoScript and uMatrix isn't showing anything being blocked from gstatic here at MSFN "at this instant" (which has a tendency to crash here lately also!). But even though my Stylus blocks the ads here at MSFN, I have a hunch that if I monitor network traffic that I will see gstatic connections here at MSFN (just a hunch, have not dived that deep yet). So I can easily see how some new ad or cookie traffic to and from gstatic can be the cause for crashes all of a sudden. But... Isn't gstatic "required" in order to log into YouTube (I don't have a YouTube login)? So it would seem that a blanket-ban to gstatic isn't really the best solution if indeed that is the root cause. For now, I'm satisfied that v12 isn't effected and I don't mind dropping to v12 for my default-for-all once I complete my modifications/tweaks/rebuild/repack of v12.

Thanks, I will try that "YouTube Redux" eventually. My Chromium v49 on XP uses an extension called "Enhancer for YouTube" which will also stabilize and tame YouTube crashes on v13. However... It's not just YouTube that used to NEVER crash any of the v13 builds but now I am getting crashes with all of the v13 builds. Dixel's v13, Humming Owl's v13, the Russian Repack v13, the Chinese original v13 - they all have major crash issues all of a sudden on XP. When those crashes started happening on "this" computer, I thought maybe a codec or something got corrupted. But I'm getting v13 crashes on XP on five different computers, all with different "levels" of Windows Updates, some with different versions of K-Lite Codec Pack, some without. I really wish I could track it down. I have honestly NEVER had YouTube crashes until just a few days ago. But... It's not just YouTube. YouTube is by far the easiest to "replicate" the crashes. But even this very MSFN forum will now crash on occasion! Axe profile completely, fresh XP install, no extensions installed, you name it, v13 has a tendency to crash all of a sudden. I've been unable to track down any realy "culprit".

It's only on XP and YT has been a total nightmare last couple of days. It bugs me because I prefer to think my browser can take anything I throw at it. I'm currently rebuilding/repacking a v12 build 1247 version and it seems to be handling YT on XP much better than v13. Video available here -- https://www.dropbox.com/s/kmhha7iz8edzbyn/v12-1247.mp4

Big NLite / NTLite Fan! @Dixel - thank you very much for letting me try your 360Chrome rebuild for YouTube testing. Sadly, your version does the same exact thing that I am seeing with all of my rebuilds which is the same thing that Humming Owl's v13 is doing. Open a second tab but try to open that tab and 360Chrome crashes. Video available here to witness -- https://www.dropbox.com/s/hkvboqbt1ctguhg/Dixel-YT-Test.mp4

I'd be interested in trying your version. I'll PM you. "Non-supported" OS and XP are still two different birds.

Ah, never knew that was there. Without a VPN, I selected a country I'm not in and very next video crashes. I wish I knew what in Hades is going on. I've never had issues with YouTube and now it's constant crashes in v13 on XP. I can jump through hoops and "stabilize" YouTube with a mix of addons, but that defeats the purpose, YouTube should be stable in Incognito Mode, I shouldn't have to jump through hoops. ZERO issues in v12 on XP so I'm actually in-process of repacking v12 and it will soon become my default-for-all. Again, crashes are ONLY in XP - with brand new profiles, on freshly installed XPs, with original Chinese, with Russian Repack, with my repack, with Humming Owl's repack -- mixing v13, YouTube, and XP is like mixing Coca Cola with Mentos or baking powder with vinegar or ammonia with bleach. I propose all future crash reports cite specifically what OS you are on. I have zero issues on my 7 and 10 partitions, it is ONLY in XP that v13 has become a YouTube Nuisance all of a sudden.

Yeah, I can increase stability by blocking everything also. But I also think it's not the route for the "average user". You and I are not "average"

on updated screencap. YouTube is still giving me issues on XP with v13 - original, Russian, modified, a dozen different builds, you-name-it, v13 doesn't like YouTube on XP all of a sudden. I actually RARELY visit YouTube, but it seems to be "thee" benchmark where users gauge stability.

1) Did not check region settings. I'm never logged into YouTube, I just visit YouTube as a guest and cache is always cleared on browser-exit. 2) I noticed that also, plus the screen cap shows the main page, not an actual video-being-played page. A screencap with that many tabs and no favicons can be "misleading", not claiming it was intentional, just "misleading". 3) Sweet! I used to use ProxHTTPSProxy also! Right around the time that a program called "Proxomitron" started to lose its following.

I remove and disable all of the "Thunder" stuff. It's basically a "download manager" and I figure if users want to use a "download manager", they will install their own extension instead of the browser coming "bundled" with one.

I pretty much spent the entire day yesterday doing nothing but forcing browser crashes. I was getting similar results with US, Canadian, and French IP Addresses so I've ruled out it being YouTube sending different code to different countries (I did not go to the extent of comparing/contrasting html source codes). Crashes were always in XP while 7 and 10 were stable. Same results on FIVE different computers, two of them multi-boot OS's - all of which have never had any "above-average-use" crashes prior to yesterday (five YouTube tabs [any more than that then I suggest a shrink no matter what browser you use!]). The crashes do not appear to be hardware-related. The crashes were always in XP and x86 vs x64 did not make much of a difference. My current course-of-action is a repack of 360Chrome v12 build 1247. It's actually been a back-burner project to eventually do a repack of v11 or v12. My stability/functionality/performance tests have focused on YouTube, Dropbox, Google Voice, and MSFN. All four were crashing various versions of different browsers. I settled on v12 build 1247 based on GUI load speed recorded by PassMark AppTimer, BrowserAudit.com results, Basemark Web 3.0 benchmark results, Speedometer 1.0 and 2.0 benchmark results, and Kraken 1.1 benchmark results. Don't really have a timeframe on repack release. I had twenty YouTube tabs running on three different computers, all XP, and I wasn't able to crash any of the v12 builds. I did not try v9 or v11 because my needs requrie Google Voice and I could not get all functionality to work in v9 or v11. Another advantage to v12 over v13 is that v12 will download .csv files from Google Sheets while v13 will not (never dug into why v13 cannot download .csv files or if there is a workaround/fix).

I moved to this city in 2001. I got my first cell phone in 2001 in order to keep in touch with friends now 3 hrs away. 3hrs is a long commute so I eventually drifted apart from the friends in my previous city. In 2004, I called up the cell phone provider and told Customer Service that I wish to cancel my cell phone plan. She didn't want to lose a good-paying customer and tapped away on her keyboard, "What if we put you in a different plan? I have a plan about a third of what you are paying now." I requested she pull up her data and tell me how many MINUTES that I have been on the phone in the past YEAR. More tapping away on her keyboard. She comes back, "Wow! Sir, it says here you have only used FOUR MINUTES in the last YEAR." I replied, "Now do you understand why I wish to cancel?" "Yes, right away sir, we have you cancelled."

Here in the States, spammers/solicitors used to never be able to call a cell phone. But then the "consumer" got STUPID and wanted to carry their land line number over to a cell phone. So now the spammers/solicitors are allowed to call land line and cell phone - all because the "consumer" got STUPID.

I haven't owned a phone since 2004. No land line. No cell phone. A very stress-free lifestyle

While you are logged in, delete past attachments from here -- https://msfn.org/board/attachments/

My only recent modification is a Humming Owl carryover -- Replaced "https://caprogram.360.cn/#plan" entry by "chrome://settings/certificate" I don't see how that could cause crashes but I rolled it back just to rule it out. But I didn't make that modification in my build 1106 and other non-2206 builds and they were crashing also, so all I can really assume is US IP Addresses. My VPN VM uses a Canadian IP Address, I'll see what YouTube does from that tomorrow. In the meantime, and if you are interested, @Dixel - can you try YouTube via VPN from a US IP Address?

The YouTube crashes are XP ONLY - x86 and x64. Does seem to be worse on x64 - but YouTube is crashing both. No issues with 7 or 10. Couldn't find my VPN VM, will revisit tomorrow. The users in the past that have reported issues with YouTube have all (or mostly) been on XP x86. Granted, most have also been SP2 versus SP3. As mentioned above though, I do think YouTube is "experimenting" with code today. It's been hit-or-miss for the better part of the day and YouTube has NEVER crashed my v13 build 2206 until today. Sure, I can "force" a crash every once in a while by being UNREALISTIC and loading up ten+ YouTube tabs - but come on, who does that OUTSIDE of trying to crash a web browser?

Didn't work (used 32bit Chrome v73 UA) - YouTube simply crashes v13 from a US IP Address. I will track down my VPN VM and try from that.

Today's experience with YouTube has me rethinking this. It has been off-and-on ALL DAY on YouTube. My modified versions (v13 builds 1006, 1032, 1054, 1106, 2206, 2216, 2220, and 2250) and Humming Owl release (v13 build 2250) - YouTube keeps crashing 360Chrome v13. I have to wonder if YouTube is "experimenting" with new code ??? But it has been hit-or-miss. Portions of the day would crash with only two YouTube tabs, portions of the day would crash with six or seven YouTube tabs, portions of the day would be stable and no crashes with 15 YouTube tabs (I didn't go any higher than 15). But with all of these hit-or-miss problems throughout the day on v13 (1006, 1032, 1054, 1106, 2206, 2216, 2220, and 2250), I could never once get v11 or v12 of 360Chrome to crash. I limited my testing today to v11 build 2031 and v12 build 1592. At one point today, when v13 was crashing at only two YouTube tabs, I was able to load TWENTY YouTube tabs in v11 and v12. All I can figure is that YouTube is "experimenting" with code. I'll load a few videos over the next few days and monitor stability. But I do like that v11 and v12 at least "survived" whatever in Hades was causing v13 to be so problematic today.

That makes sense. I was a moderator at a forum for a web filtering proxy program called "Proxomitron". Its creator passed away a few years back and I recall there being some debate at the time as to the future of "Proxomitron". I actually still use "Proxomitron", but only to send Microsoft Excel data queries through.