- Pale Moon guru
- Posts: 23030
- Joined: Sun, 28 Aug 2011, 17:27
- Location: 58°2'16"N 14°58'31"E
I'd say this is a problem; but it'd be a problem of how the browser is started, not a problem with the browser itself.
"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne
Because if I already have one instance running and I runMoonchild wrote:I'm not sure why you're starting Pale Moon with both --Profilemanager and --new-instance flags at the same time.
Code: Select all
OK. That'ss he main thing. I'm probably on the right track figuring out the pointer problem then. I can figure out another way to start PM. I can script a choose profile dohickus that bypasses the need to use the profiile manager or just hardcode separate menu entries for each profile.Moonchild wrote:The risk in doing that is that you may be creating a new hidden window/new process every time you use a URL association, causing your long listed of processes. I'd say this is a problem; but it'd be a problem of how the browser is started . . .
Lew Rockwell Fan wrote: I can script a choose profile dohickus that bypasses the need to use the profiile manager or just hardcode separate menu entries for each profile.
That's what I do... with approximately 20 profiles.
There's a wrong way
And then there's my way
If you want to do the same, while at the same time with the ability to be able to direct which instance is used to open a "link" (say from Thunderbird, or from the command line), then I believe -new-instance is appropriate. (Note: -new-instance does not apply to Windows.)
Once you have opened your (say, two) -new-instance instances, "calls" to open links in a particular instance should use the -remote switch (in conjunction with the -P switch to specify the wanted Profile) & not the -new-instance switch.
Thanks. That's interesting & may have some bearing on scripts (dealing with links under various circumstances) I may do in the future, but it doesn't seem to have any bearing on the present matter.therube wrote:If all you're wanting to do is to be able to open multiple simultaneous instances of PM, then I think you should be using the -no-remote switch (rather then -new-instance).
Code: Select all
palemoon -P profilename --new-instance
I've determined that the mouse problem is definitely caused by my old PM profile. Probably one of the extensions, but I haven't isolated it yet. Whatever it is will bog the mouse (actually trackball) driver down until it is so slow as to be useless, and sometimes it crashes altogether so that the pointer disappears and nothing done with the trackball, including buttons, ball, and wheel has any effect at all. Once it gets to that point it can't be recovered with anything I've tried short of rebooting. Even logging out, and restarting X doesn't do it. It's not just a "hasn't happened to happen yet" thing. I use the old profile, my trackball soon quits working correctly. The new profile, no problem.
Multiple htop lines, the actual title subject, appears to be a red herring. My fresh profile works fine & doesn't cause any trackball problems, but it also causes a plethora of palemoon lines in htop. I've used it long enough now to be totally confident in those assertions.
I haven't found an easy way to quantify this, short of stretching out the window repeatedly and then counting the lines. As I stated in the OP
Code: Select all
ps --wweo | grep palemoon |grep -v grep
Whatever it is, since it doesn't seem to be related to the trackball problem, figuring it out is now a lower priority for me than tracking down what extension or setting in my old profile kills my trackball. I may figure that out by restoring the same extensions and settings, a few at a time, until I break this profile the same way. Or not. At any rate, the present profile, which I back up every time I change anything, works.
After I track down the trackball killer, or give up on it, I may return to figuring out the odd htop report and the difference between what htop and ps show. I might even try the profile manager again. But for now those are more matters of curiosity than a practical issues.
Thanks. In that case htop would be equivalent to ps? I presume the thread view still represents some kind of potentially limiting resource. Otherwise, why is it useful? These questions aren't crucial to the issue I was having. I'm just curious, if you feel like furthering my education.Toa-Nuva wrote:By default, htop does indeed display threads and not just processes. In your htop screenshot, most entries show exactly the same memory usage, which means they probably belong to the same few processes. You can setup htop to only display processes by going to "Setup" > "Display options" and selecting "Hide kernel threads" and "Hide userland process threads".
Anyway, an update:
Turns out 2 things have to be going on for this problem to manifest.
1. I have to be running the problematic profile
2. I have to be running a script I was running in the background. I've inserted "exit" on a the line following the shebang and I can run either profile with no problem. The script gets called every 2 minutes and does several things that are unrelated beyond the fact that it seemed desirable to do them in the background frequently. When I uncomment the exit command, the new profile works but the old one causes the problem.
Next, I'll probably try running that script in a terminal or logging it's output. When I find out something more specific, I'll post it.
Who is online
Users browsing this forum: AhrefsBot [Crawler] and 5 guests