Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


roytam1

My build of New Moon (temp. name) a.k.a. Pale Moon fork targetting XP

Recommended Posts

@Mathwiz:

https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js

https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js#L82

https://github.com/roytam1/UXP/blob/master/application/palemoon/app/profile/palemoon.js#L927

40 minutes ago, siria said:

But perhaps I'm getting something wrong

 We need the location of the code to be modified inside the Source Code, not inside the compiled application ;) ...

Edited by VistaLover

Share this post


Link to post
Share on other sites

VistaLover said: We need the location of the code to be modified inside the Source Code, not inside the compiled application


Hmm... but what makes this so hard to understand, seen from the outside (zero clue of confusing source/dev/compiling/github stuff): in the final product there are some pref files hidden inside omni.ja, which has internally the same folder structure, but there are also some pref files freely accessible outside, in the defaults/pref or browser/defaults/preferences folder. Those I can't find inside the omni's, no duplicates. Especially K-Meleon has several files, but NewMoon at least one. They must come from somewhere too? And especially, not being embedded anywhere, and their content not refering any dll's or exe's etc, they look like they don't have much to do with 'compiling', and it would be very easy to just add those in some simpler way - like just drag-drop them there in the final zip? And in that defaults folder they override any hidden prefs in the omni's, so wouldn't matter if those still contain other pref values.

  • Upvote 1

Share this post


Link to post
Share on other sites
13 hours ago, siria said:

And especially, not being embedded anywhere, and their content not refering any dll's or exe's etc, they look like they don't have much to do with 'compiling', and it would be very easy to just add those in some simpler way - like just drag-drop them there in the final zip?

if you want to save roytam1's time for doing this before every delivery, don't go this way.

Not to say of possible problems, if the Moonchilds/Tobins/whoever elses code he forks from gets changed and incompatible with this simple drag'n'drop.

So no, if we need to get this changed and help roytam to develop this, forking his github and doing pull request as he asked is the best way.

  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites

Mcinwwl said:


if you want to save roytam1's time for doing this before every delivery, don't go this way.

Not to say of possible problems, if the Moonchilds/Tobins/whoever elses code he forks from gets changed and incompatible with this simple drag'n'drop.

So no, if we need to get this changed and help roytam to develop this, forking his github and doing pull request as he asked is the best way.


No not before every delivery. Just once. Putting the new file into the secret hiding place ;-) where the other independant non-compiled files in prefs folder are coming from too. Those are surely not manually copied every single time either.

If the original code gets changed, it will probably get exchanged in the forks too. Then all own fixes are lost if they were embedded deep in the source, and the issue must be investigated again and the fix applied again, or rather gets just forgotten. To me looks like more work not less. Provided of course the fixes are as harmless as exchanging the support URLs in a prefs file.

Of course I'm mighty glad of roytams immense work too, it blows my mind, my own browsing depends on him, and basically a single person has to 'save the world' (xp world) in his spare time ;-) No idea how he manages that, but sad enough for the state of the world today. Still just saying that I find it so extremely out of proportion, that a workload of 1000:1 for two people to reach the same goal is today considered as normal. And even as desirable. The prob is that other people are usually not bored to death either, what everyone seems to assume, and have to struggle for their own little spare time. So comparing a minute for a one-time action of copying a file, with the act of learning github, setting up an account, copying a giant mass of files, learning howt to edit and etc. from scratch, it's just so extremely... oh well, not my prob :)
(It's just that I'm too forced again and again to waste endless struggling time with stuff that experts could do with a fingersnip, but just don't care, in all areas of life)
  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites
18 hours ago, siria said:

palemoon.js in browser/omni.ja/defaults/preferences.

Thanks. I'll make the necessary fix and create another pull request, probably tonight.

17 hours ago, siria said:

But wouldn't it be a lot easier to just create a separate little prefs file in browser/defaults/preferences, as was already suggested? But perhaps I'm getting something wrong...

Tried that; surprisingly, it didn't work! Apparently these particular prefs override whatever is in that folder.

(Same goes for SSUAOs BTW; any built-in SSUAOs override whatever is in browser/defaults/preferences, although that's not as critical, since the built-in SSUAOs are supposedly correct for the NM/Serpent version being used. Adding myuseragents.js to that folder still adds the SSUAOs that aren't built in.)

Besides, we want to change the build so that everyone gets these changes, and the easiest way to do that (at least, the easiest way for me) was to fix the built-in prefs in the first place, rather than adding another file to the build to override them.

15 hours ago, siria said:

K-Meleon has several files, but NewMoon at least one. They must come from somewhere too? And especially, not being embedded anywhere, and their content not refering any dll's or exe's etc, they look like they don't have much to do with 'compiling', and it would be very easy to just add those in some simpler way - like just drag-drop them there in the final zip?

I think you're talking about the channel-prefs.js file, which sets app.update.channel to "default" for @roytam1's builds (presumably sets it to "release" or "ESR" in official builds). Yes, if a .js in that folder worked (which, unfortunately, it doesn't), I could've added the prefs to that file instead, although the name "channel-prefs.js" would then be a bit misleading ;)

Share this post


Link to post
Share on other sites
2 hours ago, Mcinwwl said:

if you want to save roytam1's time for doing this before every delivery, don't go this way.

It won't be a problem for every release. It'll only be a problem if MCP someday changes the same files I changed, and even then, I think only if MCP changes the same lines of code (otherwise I think Github can easily merge MCP's changes with mine into the final source files). Pretty sure that's why @roytam1 wanted this done by a pull request in the first place.

If MCP does happen to change those same lines of code someday, @roytam1 will need to decide which of the two conflicting prefs to use in the final build, but that shouldn't be hard and is a one-time decision anyway.

Share this post


Link to post
Share on other sites
29 minutes ago, siria said:


Of course I'm mighty glad of roytams immense work too, it blows my mind, my own browsing depends on him, and basically a single person has to 'save the world' (xp world) in his spare time ;-) No idea how he manages that, but sad enough for the state of the world today. Still just saying that I find it so extremely out of proportion, that a workload of 1000:1 for two people to reach the same goal is today considered as normal. And even as desirable. The prob is that other people are usually not bored to death either, what everyone seems to assume, and have to struggle for their own little spare time. So comparing a minute for a one-time action of copying a file, with the act of learning github, setting up an account, copying a giant mass of files, learning howt to edit and etc. from scratch, it's just so extremely... oh well, not my prob :)

As long as this is the only manual thing to be done in this project and noone else will ever as for such favour, to be done once a week for every build... sure. But give'em a finger, they'll bite your leg off, I bet you that :)

29 minutes ago, siria said:

(It's just that I'm too forced again and again to waste endless struggling time with stuff that experts could do with a fingersnip, but just don't care, in all areas of life) 

It feels like yours real-life experience speaks through you.

Mine says that if you work in heavily automated environment, or work on solving complex problems, it's hard to keep track of all those simple things that should take a while. You simply forget, because you have no habbit, or your brain is still working on a different level.

And things that look simple from outside, might turn out into heavily complex stuff if you know the whole background.

-----

And I'm coming from a position, that actually roytam1 does a big favour to the community doing those builds. We can ask him for feature request, bug fixes and so on, but asking to change his working habbits is too much. Especially, when he once replied no.

That's my final word on the topic, piece.

Share this post


Link to post
Share on other sites
33 minutes ago, Mathwiz said:
18 hours ago, siria said:

palemoon.js in browser/omni.ja/defaults/preferences.

Thanks. I'll make the necessary fix and create another pull request, probably tonight.

... Have you looked at my own post on this subject?

18 hours ago, VistaLover said:

:dubbio:

Share this post


Link to post
Share on other sites

Mathwiz said:


(Same goes for SSUAOs BTW; any built-in SSUAOs override whatever is in browser/defaults/preferences, although that's not as critical, since the built-in SSUAOs are supposedly correct for the NM/Serpent version being used. Adding myuseragents.js to that folder still adds the SSUAOs that aren't built in.)


If overriding omni prefs with external pref files doesn't work, there's something wrong. Perhaps the folder path?? Try both locations, the ancient and the new one? Many years ago in Firefox the path for defaults was changed from "Firefox/defaults/pref" to "Firefox/browser/defaults/preferences". By the way the same structure as just seen inside omni.ja Yet here in the forum it keeps me riddling that still the old path gets recommended over and over, but then again, who knows. And meanwhile saw that actually Palemoon builds etc. still do come with the old path in the zip. And quite obviously, so many experienced people here who know 100x more than myself would long since have noticed if the old path wouldn't work anymore!
But since now you're saying the external overrides don't work, here's a quick theory: What if perhaps, who knows, the browser still considers both paths as valid, but if there's conflicting content, the values in the newer default path get priority? Regardless if inside omni.ja or outside?
  • Upvote 1

Share this post


Link to post
Share on other sites

Mathwiz said: I could've added the prefs to that file instead, although the name "channel-prefs.js" would then be a bit misleading


Yep, of course they should go into an own new file. Like newmoon.js or whatever, name can be freely chosen.

@Mcinwwl: I'm all for automation too if possible. Sorry that I mentioned exchanging the file in the final zip, that was misleading and rather meant to just show how harmless those files are. Or even if done that way, that copy process could certainly be automaticed too by skilled people. But what I originally meant was just to add that new file in the same place where the other sibling files are coming from too. Those sure are included automatically too.
The only thing that makes me not 100% sure is if possibly any checksums or whatever may have to match, no clue about such stuff.

Share this post


Link to post
Share on other sites

Thanks @VistaLover. PM has a "slow startup" help page? (FF and Serpent don't seem to.) Do you have a suggested replacement URL? (For app.support.baseURL I was just going to point to Mozilla.)

10 minutes ago, siria said:

If overriding omni prefs with external pref files doesn't work, there's something wrong. Perhaps the folder path?? Try both locations, the ancient and the new one? Many years ago in Firefox the path for defaults was changed from "Firefox/defaults/pref" to "Firefox/browser/defaults/preferences".

Yeah, I tried both. Actually I tried <install dir>/defaults/pref first, since that path already existed; when it didn't work I created defaults/preferences/ under browser/ but had the same result: it added new prefs but didn't override the built-in ones.

It probably depends on the order the .js files are run at startup, with the last file to set a pref "winning."

Now I didn't try it with Firefox, so maybe it works there, but we're not changing FF! I tried with both Serpent and New Moon and got that result.

In the omni.ja I extracted, there are several subdirectories under defaults/: autoconfig/, pref/, and preferences/. I haven't done extensive testing but at this point it appears the contents of preferences/ are run last; hence, can't be overridden (except by user prefs). It's certainly possible MCP changed the order these run at startup.

3 minutes ago, siria said:

Yep, of course they should go into an own new file. Like newmoon.js or whatever, name can be freely chosen.

Or maybe even palemoon-branding.js, which is the one I changed ;) (unofficial branch only, of course).

  • Like 1

Share this post


Link to post
Share on other sites
55 minutes ago, Mathwiz said:

For app.support.baseURL I was just going to point to Mozilla

... And why would you not link to this very MSFN thread? :dubbio:It would be consistent with what is already displayed in @roytam1's binary repository:

https://o.rths.cf/palemoon/?sort=date&order=desc

Index of /palemoon/

Welcome to New Moon (a.k.a. Pale Moon fork targetting XP) binary directory.
These projects have no affiliation with any upstream community code sources or organizations. Please direct all support or related questions to disscussion thread in msfn.org.

So, my recommendation would be:

app.support.baseURL;https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/

WRT http://www.palemoon.org/support/slowstartup.shtml , this is just an adaptation from the corresponding Firefox guide:

https://support.mozilla.org/en-US/kb/firefox-takes-long-time-start-up

Admittedly, the PM page is better tailored to New Moon users, but, again, that page is copyrighted to MCP and has references to official app name, logo and support forum, so... :}

Perhaps @dencorso can somehow transplant the following text: 

Quote

Slow startup detected

It seems that New Moon is taking much longer than normal to start.
 

What happened?

New Moon, as part of normal monitoring of its process, has detected that starting the browser is taking much longer than it should. This can have multiple reasons:

Your computer is very busy due to other running programs, slowing the start of Pale Moon.

Your computer is low on memory.

There is a problem with your session store (saved windows and tabs from last time) causing a large delay.

There is a problem with one or more extensions, delaying the startup of the browser.

What can I do to fix this?

If you run into this regularly, you should examine what the cause is using the above points.
If your computer is low on memory, considering adding more memory or closing resident programs.
If there is a delay because you are using a very large number of tabs, consider using bookmarks instead.
Examine your extensions and check for any incompatibilities.

You can also try to give New Moon a fresh start with your data by performing a profile reset. To do this, go to Help -> troubleshooting information... and use the "Reset" button top-right, if present. In some situations this button may nor be present, in which case you should create a fresh profile; for more assistance with that, please visit our dedicated MSFN thread.

as second post to this very thread, then the URI to that post could be used as value of pref browser.slowstartup.help.url  ;)

( I am against this myself, but one can supposedly disable a "slow start-up" page from appearing by toggling pref:

browser.slowStartup.notificationDisabled; this will disable the notification and the access to the support page ).

Edited by VistaLover

Share this post


Link to post
Share on other sites
1 hour ago, VistaLover said:

And why would you not link to this very MSFN thread?

Well, I just put in a change to point "Submit Feedback" here (in both Serpent and New Moon).

I could point "<browser> Help" to the same place, but in Serpent there's a problem:

On 6/3/2019 at 10:17 AM, Mathwiz said:

Oops: Discovered a minor wrinkle with changing app.support.BaseURL: Help / Keyboard Shortcuts no longer works :( So it might be best to just revert to Mozilla for that pref. 

Serpent already points to Mozilla, so no change is needed there.

New Moon doesn't have the "Keyboard Shortcuts" option, so we can change it. But I don't want to point two Help menu options to the same place.

So how about this: I'll point "New Moon Help" to the first post of this thread, where @roytam1's FAQ is. I pointed "Submit Feedback" to the first new post (of course you have to be signed into MSFN for that to work), so the user can contribute to the discussion.

Share this post


Link to post
Share on other sites
2 hours ago, VistaLover said:

To keep things simple for now, let's just redirect browser.slowstartup.help.url to the above Mozilla page. Unlike Matt et al., Mozilla won't mind: Basilisk / Serpent already point to Mozilla pages for several purposes.

Longer term, we can use this thread to host additional New Moon / Serpent support pages, including the one above. But the short-term goal is just to avoid inadvertently directing New Moon users to palemoon.org where they might expect support.

Share this post


Link to post
Share on other sites
43 minutes ago, Mathwiz said:

I could point "<browser> Help" to the same place, but in Serpent there's a problem:

On 6/3/2019 at 6:17 PM, Mathwiz said:

Oops: Discovered a minor wrinkle with changing app.support.BaseURL: Help / Keyboard Shortcuts no longer works :( So it might be best to just revert to Mozilla for that pref. 

This is a tough one to solve :(; selecting in Serpent 52.9.0 "Help => Keyboard Shortcuts" is, code-wise, contained in:

https://github.com/roytam1/UXP/blob/master/application/basilisk/base/content/baseMenuOverlay.xul#L55-L56

        <menuitem id="menu_keyboardShortcuts"
                  oncommand="openHelpLink('keyboard-shortcuts')"

The code to execute the command is contained within:

https://github.com/roytam1/UXP/blob/master/application/basilisk/base/content/utilityOverlay.js#L818-L823

function getHelpLinkURL(aHelpTopic) {
  var url = Components.classes["@mozilla.org/toolkit/URLFormatterService;1"]
                      .getService(Components.interfaces.nsIURLFormatter)
                      .formatURLPref("app.support.baseURL");
  return url + aHelpTopic;
}

The default value for app.support.baseURL is

https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/

so the URL returned is

https://support.mozilla.org/1/firefox/52.9.0/WINNT/en-US/keyboard-shortcuts

which then auto-redirects to

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly?redirectlocale=en-US&as=u&redirectslug=Keyboard+shortcuts&utm_source=inproduct

... As for the browser.slowstartup.help.url, I merely proposed what appeared to me as a simple (but functional) enough solution, provided @dencorso obliges ;); but, since this is basically your PR and your call, you are free to proceed as you see fit... :)

  • Like 1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...