Jump to content

My Browser Builds (Part 1)

roytam1
 Share

Recommended Posts

VistaLover

VistaLover

Posted
Posted

@mraeryceos

... My previous assessment was based on your initial report, stating that:

On 8/1/2019 at 5:06 AM, mraeryceos said:

I tried several things, which eventually led me to rebuild my browser from scratch.

and I took (perhaps mistakenly?) "rebuild my browser from scratch" to mean build a new New Moon 28 profile from scratch; but you're now possibly contradicting yourself, as in:

28 minutes ago, mraeryceos said:

I ended up continuing to use the browser profile without rebuilding it from scratch :-)

So, which was it? In any case, I'm more than happy you ended up with a smooth-running browser! :cheerleader:

Link to comment
Share on other sites

VistaLover

VistaLover

Posted
Posted (edited)
19 hours ago, roytam1 said:

official build got errors as well

Many thanks for checking this out :wub:

19 hours ago, roytam1 said:

but it is not good to post bug report to their side with my account.

With all due respect, how is this going to contribute to current/future bug resolution on the UXP platform, that we also share here? 

1. Moonchild won't accept bug reports if they came from unbranded forks (NM28+St52) users (if you ask me, he himself should test if present in his official builds, before dismissing those users, but all parties here realize this is never gonna happen!)

2. Effort has been taken recently in these forks (with initial requests by @TechnoRelic and other members, put in place by PRs kindly authored by @Mathwiz) to direct all issue reports here and, ultimately, to have them reviewed by the forks' maintainer, i.e. you :)

3. I'd argue that the majority of the fork(s) users do so because, either by choice or necessity, find themselves using an OS not sanctioned by the upstream devs (namely XP and Vista), and who (which is currently the case with me) don't have immediate/easy access to the officially sanctioned/supported OSes (Win7+).

4. Moonchild, in general, dislikes people posting issues directly in his GitHub issue tracker (apparently only reserved to a team of selected developers/"sidekicks"), instead prefers his users to post first to the official forum, and then he could "triage" them there as he sees fit <_<.

My humble opinion is that you should post the issue in the forums, with concrete proof it was diagnosed in an official build (so, no references or links to here); that way, Moonchild will have no justification to dismiss the bug report, even if it came from his worst enemy on this planet (which, obviously, you're not! :)).

I see only two other approaches:

1. Somehow push code yourself to your custom UXP branch to rectify reported issue(s) on your own.

2. This broader community is otherwise in need of a person/member that:

a. Has a (whitelisted) official forum (forum.palemoon.org) account
b. Optionally, has also a GitHub account
c. Is a user of a UXP forked application, namely New Moon 28 and Serpent 52.9.0
d. Has easy access to an OS that supports the official counterpart applications, i.e. Pale Moon 28 and Basilisk 52.9.20xx.xx.xx)
e. Is able to reproduce/confirm bugs (found initially in the forks) in the official builds. 
f. Is able to post a no-frills coherent report in the forums, and then let MCP et co. do the rest

FWIW, last time I asked a favour from such a person, he kindly declined (and I have no right whatsoever to blame him...).

Again, this is NOT about my petty bug (for which I've already found and posted a working fix); it's about the course of actions one is supposed to follow with regards to meaningful UXP bug report and hopeful resolution!

Thanks again for your time reading this, thanks eternally for your efforts and binaries :wub:

(... back now to deploying a strategy on how to combat a 42 Celsius heatwave pestering us for the next two days :()

Edited by VistaLover
English
1
Link to comment
Share on other sites
mraeryceos

mraeryceos

Posted
Posted

@VistaLover

I started rebuilding the browser from scratch (yes the profile, but also another folder with another instance of the program files).  I started to, is the key phrase here.  I didn't continue, because I noticed that I was no longer having issues with CPU racing.  The only thing I changed was the --no-remote switch.  So now I am back to using the old profile, and the old program files that have been updated-in-place several times over the years.

Sorry, I thought it was clear.

1
Link to comment
Share on other sites
siria

siria

Posted
Posted

(PM28, WinXP)

mraeryceos said:


I started rebuilding the browser from scratch (yes the profile, but also another folder with another instance of the program files). I started to, is the key phrase here. I didn't continue, because I noticed that I was no longer having issues with CPU racing. The only thing I changed was the --no-remote switch. So now I am back to using the old profile, and the old program files that have been updated-in-place several times over the years.


Very interesting. Were the culprits some specific websites, or just in the sense of "too many tabs open"?
Makes me wonder why this happens. Anyone have a guess?
Link to comment
Share on other sites
Mathwiz

Mathwiz

Posted
Posted
On 8/1/2019 at 5:00 PM, Mathwiz said:

Without uBlock Origin Updater, Serpent 55 (Moebius) will self-update to 1.18.4 (or possibly later)

 

On 8/1/2019 at 7:28 PM, VistaLover said:

Not according to tests I conducted prior to my reply above...

Steps to reproduce... (removed for brevity; see above)

Well, you're right - but so was I.

There are two update mechanisms in FF and its offshoots: manual and automatic. And believe it or not (I certainly didn't believe it until I confirmed it myself) on Serpent 55, they yield different results!

As you found, the manual process (where you ask the browser to check for updates) stops at 1.17.4. But the automatic process will eventually offer 1.21.2 (which is broken on St 55, as you noted). What the heck is going on here anyway?

I think I found the answer in these two prefs: 

extensions.update.background.url;https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=53.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

You'll have to scroll to the right to see the relevant difference (it's subtle). The "appVersion=" query string passed to the server is the variable %APP_VERSION% in the extensions.update.background.url pref, but it's hard-coded as 53.0 in the extensions.update.url pref!

As it happens, uBO version 1.17.4 is the latest version claiming to run on FF versions 52.0 through 54.0. All later versions claim 55.0 or later is required. So when you manually check for updates, AMO only offers uBO version 1.17.4. but when the browser does it automatically, %APP_VERSION% gets replaced with 55.0, so AMO offers the latest version (1.21.2).

This discrepancy goes back at least as far as the 3/10/2018 version of Serpent 55. I'm surprised no one has stumbled across it before now. I'm guessing the hard-coded 53.0 was meant to fix incompatible updates being offered (Serpent 55 was forked from FF 53, with only a few changes back-ported from FF 54 and FF 55, so many add-ons targeted at FF 54 or 55 won't run, now including uBO 1.21.2), but whoever put it in (MCP?) forgot to make the same fix to the background pref. It would make more sense to hard-code 53.0 in both update prefs and eliminate this oddity.

Side note: if you go to about:addons, click Get Add-Ons, then click Find More Add-Ons, what AMO offers depends on your user agent. By default, it won't offer anything except a download of Firefox (even in FF compatibility mode), but if you use, say, a SSUAO to provide a "pure" FF user agent, it will offer either 1.17.4 or 1.21.2, depending on which FF version you pretend to be.

If you want to "live on the edge," you could put 55.0 in a SSUAO for AMO. If you also fix the background update pref, you wouldn't be offered any uBO updates past 1.17.4, but could still manually browse AMO and try later versions to see if they work (as mentioned, 1.18.4 will and 1.21.2 won't, but I haven't tried versions in between to find out where the "cutoff" is).

2
Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted
5 hours ago, VistaLover said:

how is this going to contribute to current/future bug resolution on the UXP platform, that we also share here? 

Mark's side should be fine for my bug report, just Matt's reaction is problematic. To prevent over-reaction from Matt, I'd prefer not posting bug reports.

But I think people may register in PM forum with different username and post bug report there.

Link to comment
Share on other sites
Vistaboy

Vistaboy

Posted
Posted
On 7/18/2019 at 7:32 PM, siria said:

Please elaborate, to figure out solutions?
The prob is, K-Meleon may be missing some essential things, but it also has lots of hidden features which simply aren't visible to unexperienced users.
For example most buttons have a handy right-click menu, which most people never discover just because they have no little-arrow as indication (example Home or Go-buttons)
A killer feature is the hidden privbar (View > Toolbars) with buttons for 1-click toggle of javascript, cookies etc.
Or the "about:about" page has lots of working links to more settings, incl. about:addons, which are not found anywhere in the menus, just because the GUI hasn't been updated in the last ten years or so, only the engine (install macro aboutabout to get at least a makeshift-menu)
Copy+search: select a text in a webpage and hit the search button (or similarly: select a text LINK and hit the Go-button)
Duplicate a tab: pull the tab into an empty space on tab bar (if any left ;-), or right-click on Go-button
If you want a closing cross on tabs: guess for this there's actually a GUI somewhere, perhaps in F2... (would have to look it up, am myself stuck on old version)
There are also macros for easy useragent-toggling, I recommend my "useragents2018" which also helps for easier managing site-UAs.

Thanks for the tips, the F2 open a world of personalization included close-tab-cross on tab. Indeed it's a browser more advanced then others about "mouse gesture". For example you can close a tab just double clicking on the tab itself.

Link to comment
Share on other sites
mraeryceos

mraeryceos

Posted
Posted
13 hours ago, siria said:

(PM28, WinXP)

 


Very interesting. Were the culprits some specific websites, or just in the sense of "too many tabs open"?
Makes me wonder why this happens. Anyone have a guess?

I was suspecting specific websites at first.  Fiverr, Upwork, Facebook.  The number of tabs open didn't matter.  The CPU would stay at nearly 50%, eating up one of my cores.  So disruptive was the situation, that I attempted, at first, to use Ublock Origin to disable individual scripts using the logger.  Then I abandoning that effort and tried to rebuild the browser, in the process discovering the --no-remote solution.

I don't want to say with any certainty, that it was specific websites.  It may not have been specific websites.  Simple websites seemed to be much less of a trigger?  I started offloading problematic websites to tabs on K-Meleon, until, finally, a website I didn't expect to be a problem also caused the CPU issue.

Link to comment
Share on other sites
Mathwiz

Mathwiz

Posted
Posted
2 hours ago, Vistaboy said:

Links (not only for KM) are unreachable

Yes, that's the same problem @Sampei.Nihira was having. Cloudflare seems to have some sort of routing problem between much of Europe (but not all; Greece reportedly is fine) and Roytam's server.

@Sampei.Nihira found a free Web proxy that let him work around the problem. Look a couple of pages back and you should be able to find his post.

1
Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted
18 minutes ago, ~~KILOE~~ said:

@Vistaboy
Have you tried pinging o.rths.cf?

 

because of cloudflare's network structure, the outer-endpoint is fine as its error page states, there seems to be a network routing problem between cloudflare's europe nodes and my server.

1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...