NotHereToPlayGames

Finally got around to trying this and meeting is logged in and waiting for actual start time, looks good so far. Thanks again.

The gmx site is leaps and bounds better with 11.2.3.0. MSFN worked fine with 11.2.4.0 but was horrible with 11.2.9.0 and 11.2.10.0. Running with 11.2.3.0 for my config.

I started googling around for this issue and there have been several reports that seems to isolate it to cap_unchecked_css and reports that it actually started with 11.2.4.0 on some web sites (the most-often cited is gmx.de) and these users reverted to 11.2.3.0. I do use the legacy 5.1.9 for my MyPal and NM browsers, but I think I'll stick with 11.2.4.0 for my Chromium browsers but will drop down to 11.2.3.0 if I see this happening more often (I don't get this with 11.2.4.0 but other users report that they do). I do get the "page flow lag" here - https://www.gmx.net/ Will revisit later today with 11.2.3.0 instead of with 11.2.4.0.

It's not really about the moment of the page loading, but the manner in which it renders. I followed the Scientific Method six times (ie, I only changed one variable [NoScript version, same profile otherwise and same NoScript settings] and the "page flow rendering" exists in 11.2.10.0 and in 11.2.9.0 but does not exist in 11.2.4.0. For the time being, I have reverted to 11.2.4.0 - may try legacy 5.1.9 later as NoScript is the only extension I use that takes up so much memory that it shows up in the browser's Task Manager.

So I updated my profile today and upgraded my NoScript 11.2.4.0 to 11.2.10.0. Thouroughly unimpressed! For example, when you load MSFN with a clean cache, the page displays "while" it is loading. You get the broken menu and a long list of menu items because the menu hasn't fully loaded yet but the browser is trying to render what portions have loaded. Reminds me of how Opera had a setting to display pages "instantly" or after 1 second and pages would just "look better" if you told Opera to WAIT 1sec before displaying the page. Watching the page "flow" into existence while resources are loading is a bit "tacky" in my opinion. Confirmed by reverting back to 11.2.4.0 and the "page flow" went away. Upgraded again to 11.2.10.0 and the "page flow" tackiness returned. Anyone else notice this issue with the latest NoScript? Maybe it's something that showed up in a version somewhere between 11.2.4.0 and 11.2.10.0?

v13 build 2206 rebuild 2 file size == 90.0 MB v13 build 2206 rebuild 3 file size == 70.2 MB login resources have been removed (which also removed Avatar context menu [may bring it back in a later rebuild to use as dropdown for chrome URLs]) @Humming Owl's v12 modfications have been ported to v13 -- no more gstatic connection on First Run --- I have not tested for possible side effects but will report if I do find any all settings pages fit in one 1920x1080 viewport - it always bugged me that you could be three dialogs in, close that third dialog, and the second dialog defaulted itself back to the top and you have to find where you were at, just annoying so I fit all to one page https://dl.dropboxusercontent.com/s/qyyimm3h58r3963/360Chrome%202206%20rebuild%203%20-%20unran%20-%20MSFN.zip

@Humming Owl - have you observed any of your modifications breaking 'internal' Unicode support? As an example, in Modified v12, you have an entry where you changed "Edit Search Engines(&E)..." to "Edit Search Engines..." And both the original and the replacement entry are THREE DOTS. But a Unicode entry of … instead of ... (highlight each of those and you will see that one is one character (unicode horizontal ellipsis) and the other is three characters (three dots) will be shown as a square in the GUI (ie, unicode support is broken). Another example, there is an entry in your notes where you changed "More…" (original with unicode horizontal ellipsis) to "More..." (you replaced unicode horizontal ellipsis with three dots, directly above "speeded" to "Speeded" entry in v12 notes) - did you do this because of a square being rendered in your GUI? I ask because the original untouched 360EE (v13 at least) does allow unicode characters but somewhere along the line both you and I are now using non-unicode throughout. I don't know "where" along the lines that the original unicode support broke but at the same time we haven't broke unicode support for the web pages that we are rendering, only the text strings of the GUI.

Thanks to some suggestions by @Humming Owl from his Modified v12, I can hereby report that v13 build 2206 rebuild 3 makes ZERO connections on First Run. Let it sit open for 20 minutes on about:blank without visting any sites, never made any connections in that entire 20 minutes (this was the case for rebuild 2 also, aside from First Run gstatic connection within seconds of launch). Navigated every settings page, never made any connections the entire time (never actually tested this in rebuild 2, it might have done a favicon connection in the Search Engines settings, not positive). Closed and relaunched three times, never made any connections (this was also the case for rebuild 2). I should be ready to upload v13 build 2206 rebuild 3 sometime tomorrow.

Task Manager memory usage, no extensions, no page visited -- v13 build 2206 rebuild 2 == 83,508K v13 build 2206 RuPack == 81,700K v13 build 2206 rebuild 3 == 80,388K

Has anyone figured out what .css entry/entries can be tweaked to fix this nuance? I'm in v13 and I think this nuance exists in earlier versions also but not 100% sure on that. When you are in settings and on the Advanced tab, open the Content settings dialog. Take note of how everything is positioned on the Content settings dialog - particularly the header title. Now open any of the Manage buttons. Another dialog will open above the Content settings dialog. But the header title of the Content settings dialog disappears and everything below it shifts up. Watch the small portions of the Content settings dialong that are still visible along the left edge of the Manage dialog that is now on top, close the Manage dialog and you'll watch everything shift back down and the header title reappear.

Got it, thanks!

Settings - Lab remove Magnifier utility (enabled website dialog never seemed to work so opting to just remove)

removed decompress with 360 from download section (this downloads a "360zip" utility and this is broken once we removed all of the telemetry - plus, we all have our own preferred archive utility external to our browser)

saving these two to-do's for a future rebuild -- 1) Location Bar -> convert Chinese copy paste helper to English (.png) 2) Page Utility -> convert Chinese video tips to English (.png)

ported Humming Owl's v12 "shared.ydstatic.com", "95001111", "googleapis" and "gstatic" entries by dots -- have not tested remainder of entries in Humming Owl's list has already been replaced (or did not exit in v13).

Do you recall why the below section was replaced for v12? - Offset (h) = 02bc54a0 Replaced the "68 74 74 70 3A 2F 2F 73 6F 2E 33 36 30 2E 63 6E 2F 73 3F 71 3D 25 73 26 73 72 63 3D 33 36 30 63 68 72 6F 6D 65 5F 61 64 64 72 26 69 65 3D 75 74 66 2D 38 00 68 74 74 70 3A 2F 2F 77 77 77 2E 62 61 69 64 75 2E 63 6F 6D 2F 62 61 69 64 75 3F 77 6F 72 64 3D 25 73 00 68 74 74 70 3A 2F 2F 63 6E 2E 62 69 6E 67 2E 63 6F 6D 2F 73 65 61 72 63 68 3F 71 3D 25 73 00 26 69 65 3D 00 26 75 65 3D" hexadecimal code by 00 hexadecimal values

removed adfilter exceptions (adfilter functionality already disabled but now exceptions list is empty) (see Humming Owl's notes) removed default search engines (see Humming Owl's notes)

Settings - UI Style functionality has already been broken, removed more items (see Humming Owl's notes), removed from GUI

Thanks!

Disregard. This "might" be related to Settings - Advanced -> HTTPS/SSL -> intercept certificate risk option (I don't use this option but at the same time am mindful to not "break" any options that I don't use but that others may opt to use).

Settings - Basics removed and disabled search engine built-in fallback (see Humming Owl's notes)

I've also opted to remove the root directory sslblock.zip. This was used in earlier versions but I have yet to witness this page ever be displayed in v13. From the best I can gather, all ssl cert errors are displayed via clicking the padlock icon in v13's address bar. That and as far as lightweight, fast, and efficient, I'm content with just the ssl error code in the title bar and a completely blank page in the content area. My only way of really testing has been this site -- https://badssl.com/

I just ran an SRWare Iron v48 (could not find a v49) first-run and saw two Google connections and one Microsoft connection all within 10 seconds of launch. Then it proceeded to connect to some Google Translate IP Addresses when navigating around in the settings pages. At that point, I exited because this has become a total and complete waste of time in my view. And I may have missed a few because I had to set the startup page to about:blank - which should be the out-of-the-box default for ALL browsers (you can't really catch all startup shenanigans when it is loading a "default page"). We really are blowing this single solitary gstatic connection way out of proportion. Because EVERYTHING that I have looked at shows us to have 360Chrome down to one single solitary gstatic connection with no unique identifier of any kind and every other browser on the planet is making SEVERAL "connections" that nobody seems to really even care about. No offense guys, as I've reported over and over, this project isn't about compiling Iron 2.0 (but we can't call it that now, Iron makes first-run connections also!), it is about creating a browser we can "trust". We will never satisfy the Archie McPhee Tin Foil Hat crowd. I wholly and fully "trust" 360Chrome - even moreso after watching connections being made by other browsers whose user-base just trusts them blindly without question.

There's a search feature? <just joking...> The maintenance caught me offguard, lost a fairly lengthy in-process post but it is what it is

I wasn't surprised, to be honest. I used to use Comodo Firewall and setting up rules for Firefox was always very tricky and time-consuming (unless you just wanted to tell Comodo to "trust" Firefox, which was never my route!). Firefox has always done some very strange stuff on startup. They conducted their test in a similar fashion to how I tend to - NO STARTUP PAGE (it's tricky to isolate first-run shenanigans if you throw a startup page into the frey), no profile, launch and let it sit there for TEN MINUTES without opening anything, don't go to any web site, don't open any settings page, don't click anywhere, just let it SIT THERE. Then click around in the GUI while still monitoring net traffic. Then close and relaunch and continue to monitor net traffic. My 360Chrome v13 build 2206 only has the ONE gstatic connection and it has no unique identifiers that I can find (I welcome anybody to screencap evidence to the contrary because that would shift priorities). But just citing its presence is kinda propaganda, smear tactics, undo paranoia, you can decide for yourselves how to "label" it. I myself (until proven otherwise) find it not only HARMLESS, but it's been there for DECADES in all Chromium builds. Again, I am of the persuasion that IF it was NOT harmless, then there would have been a hanging in the town square and the revolution would have been televised. Or something like that...