Pale Moon forum

There seems to be a rather unnerving start-up bug in version 28.0.0. Whenever I start the browser (cold or warm), it wants to "stretch" most of the width of my screen, but NOT all of it. Please refer to this topic for some details: viewtopic.php?f=37&t=20138 . What really concerns me is that helloimustbegoing's "workaround" does NOT work at all for me. In addition, it takes about 2 FULL seconds before PaleMoon will maximize, which makes me very nervous. Instead, it wants to stop 64 pixels shy of the right border of my screen, where I have a dock (Fluxbox & Blackbox call it a "slit"). I never experienced the hesitation to maximize with ANY previous PaleMoon release. Believe me, my window manager has nothing to do with it, as anything is allowed to cover the slit.
I'm using 32-bit PaleMoon for Linux and have no other complaints about the new release. Please, please try to fix this bug, and thanks.
arkaland

I don't think this bug is specific to 64 or 32 bit linux Pale Moon. The same thing occurs at start up with 64 or 32 bit linux SeaMonkey.

Thanks for the reply, Night Wing. If it's really true that SeaMonkey exhibits the same behavior, that is no real consolation at all. Once again ( let me make this perfectly clear), this erratic start-up behavior was NEVER present in any previous Linux release of Pale Moon (and I've been a loyal PM user for years now). So I hate to come right out and say it, but a Pale Moon developer needs to compare the UXP-based start-up code in 28.0.0 with the previous start-up code in PM 27 so as to (hopefully) find a way to modify it in PM 28. I realize that UXP is different "under the hood", but let's not let Pale Moon just become another SeaMonkey.

With 64 bit linux Pale Moon 28.0.0 and the other linux browsers I use in 64 bit linux Mint 19 (64 bit SeaMonkey 2.49.4, 64 bit Firefox 61.0.1), I have all of my linux browsers set to open in maximize mode upon start up. The event you're describing happens with both Pale Moon and SeaMonkey, but for me, the event only lasts about half a second in time. This is why I had not noticed it before because it manifests itself on the far right side of my 27" external monitor for both of my desktop tower computers.

As an oddity, it does "not" happen with linux Firefox. But both Pale Moon and SeaMonkey open way quicker than Firefox. This is just a guess on my part, but it may not be showing up in Firefox because Firefox is much slower to open in a maximized state at start up. I'm wondering if this is happening in that slower state and then when the browser opens, the problem isn't seen, but it is still there.

Another guess of mine is, this bug in linux Pale Moon and linux SeaMonkey may just be unique to linux distros. I use Mint, but I have a feeling you don't use Mint. I'm guessing you use a different linux distro.

2 FULL seconds before PaleMoon will maximize

Does that still occur if you restart in Safe Mode?

therube wrote:

2 FULL seconds before PaleMoon will maximize

Does that still occur if you restart in Safe Mode?

I know you directed the above for arkaland, but I thought I would chime in to let you know what extensions I use.

The only extenisons I use in linux Pale Moon 28.0.0 are:

Adblock Latitude
NoSquint

The only extensions I use in linux SeaMonkey 2.49.4 are:

Adblock Plus

The only extensions I use in linux Firefox 61.0.1 are:

Adblock Plus
Zoom Page WE

As you can see. Three linux browsers, three different extensions for all three browsers.

I am thankful for the attention Night Wing & therube have given my report, but I honestly cannot see why "Safe Mode" (which I have NEVER resorted to) would make the slightest difference in the start-up behavior. I am using fewer than a dozen extensions, ALL of which I have used for a long, long time. And THAT is my main point: not one single previous release of Pale Moon has exhibited the erratic start-up behavior. I have tried deleting my "xulstore.json" file and forcing a new one to be created -- NO HELP. I've even tried several things with "Devilspie2" which uses LUA & libwnck 2 -- even with that -- no help (and devilspie2 NEVER failed me before).
The nutty start-up behavior is definitely a (UXP) bug, which does need to be addressed.

arkaland wrote:I am thankful for the attention Night Wing & therube have given my report, but I honestly cannot see why "Safe Mode" (which I have NEVER resorted to) would make the slightest difference in the start-up behavior. I am using fewer than a dozen extensions, ALL of which I have used for a long, long time. And THAT is my main point: not one single previous release of Pale Moon has exhibited the erratic start-up behavior. I have tried deleting my "xulstore.json" file and forcing a new one to be created -- NO HELP. I've even tried several things with "Devilspie2" which uses LUA & libwnck 2 -- even with that -- no help (and devilspie2 NEVER failed me before).
The nutty start-up behavior is definitely a (UXP) bug, which does need to be addressed.

PM 28 is a major platform upgrade; a number of changes occurred, and any number of extensions that "worked forever" may not work any more. If you can narrow down which of your extensions are affected by temporarily disabling them (e.g. via Safe Mode), that would greatly help with troubleshooting efforts.

OK, guys, I tried 28.0.1 in SAFE MODE. There is absolutely no difference in the start-up behavior as I reported above. And, by the way, I've been using 32-bit Linux exclusively since February of 2006. My distro, my window manager (I don't need any "desktop environment"), AND my extensions (which all seem to work, thank God) simply do NOT have anything to do with this. It's a BUG in PM 28 for Linux -- pure and simple. Saying that it's a UXP thing (like in SeaMonkey), or that its "no big deal" doesn't change it and does nothing to fix it. To me, it IS a big deal. And telling me about a "major upgrade" and "big changes" is silly -- I've been aware of that from the start. If no one is willing to make an effort to find & fix this bug, then just be honest and say so. I am starting to fear that the Pale Moon I've known & loved for more than 4 years now is changing all right -- but NOT for better, but worse.

Apparently what is happening is that Palemoon is starting up at the last screen coordinates that it inhabited when last run in a non-maximized state. The results are identical whether started up with addons or started in safe mode. They are also replicable, and occur regardless of the screen resolution. (I tried three screen resolutions).

How to replicate:

1. Size the browser window to about 1/2 the screen width. Now maximize the browser window to take up the full screen width.

2: Exit, restart Palemoon.

Anticipated result. PM would start up fully maximized.

Actual result. PM's rightmost edge pauses for one to three seconds at the center of the screen - the exact position it previously occupied - after which it sluggishly extends itself rightward to the fully maximized state.

An associated glitch is that while in the unmaximized state, grabbing the browser by the top and sliding it from side-to-side quickly results in the right edge becoming "pliable," as the right edge leaves visible traces on the screen. This does not occur with any other programs. (SMPlayer, Geany, UFW, LibreOffice Writer).

Assigning a nice value of 4 in Firejail helps greatly. Same results, however, inside and outside of Firejail, regardless of screen resolution, and regardless of whether PM is in Safe Mode. The browser is also far more prone to crashes than were previous versions. This may be significantly ameliorated with Das-Watchdog.

Compositor settings: compton --backend glx --unredir-if-possible --glx-no-stencil --glx-no-rebind-pixmap --glx-swap-method buffer-age --vsync opengl-swc. Snappy windows, with no visible tearing whatsover.

OS: Bastardized MX-17 with System-D components removed. Dell Optiplex dual-core desktop with standard issue Intel graphics running Nouveau.

Thomas0038, thank you for your kind attention and input. If the PM for Linux developers will read your reply carefully, they'll definitely gain some worthwhile input about this troublesome bug. Even Devilspie2 cannot correct the crazy startup behavior. And, please note that I screwed up when I titled my initial post -- I should've said "...in PM 28", not "28.0.0". There is NO improvement where this bug is concerned in v. 28.0.1 -- none.
So, while I hate to be a persistent "pain in the a--" about this, I do feel compelled to ask, is there ANYONE on the Pale Moon for Linux development "team" who is willing to try to diagnose and then fix this bug? And yes, I realize it's undoubtedly UXP-specific, but when you're committed to going with the UXP technology, does that mean that we must give up all hope of fixing something like this?
I honestly do NOT want to feel forced to search for a different "default" Web browser. I still love Pale Moon, but I sure-as-he-- do NOT love Pale Moon 28. If someone -- anyone -- with sufficient know-how would make a serious effort to fix this startup bug, then my peace-of-mind would be restored.

After tweaking a padding width/height Openbox theme to have a title bar of the size Almost i do not have the issue anymore. Or at least my eyes does not find out anymore. I fixed early to PM 28.0.1.

I'm trying the latest version 28.1.0 (32-bit), I'm not sure twaking Openbox padding made a fix or new version helped.
So please do check on current version and tell your finding regarding geometry.

I have better startup Pale Moon now on Devuan 1 (jessie)
By the way, many thanks Moonchild and the PM Team for the support.

Regards!

arkaland, what distro and desktop environment do you use? If you don't use a de, what window manager do you have?

I've been using a modified version of Slackware which I basically maintain myself. Being retired, I have the time, plus my package manager gives me great flexibility when it comes to adding or removing packages. By the way, I am not missing any dependencies
of any kind.
As far as my window manager is concerned, I usually use (and prefer) Blackbox (version 0.70.2 - the CVS version) which is definitely better than the old 0.70.1.

After reading and re-reading my previous post, I realized that I may
have given out a wrong impression. While I do compile most of the
software and upgrades that I use for myself, I have NEVER compiled
(or even tried to compile) Pale Moon. The main reason is very simple:
my 32-bit computer doesn't meet the requirements for compiling
a full-featured Web browser. I have always installed Pale Moon by
downloading the official tar.bz2 file on the Pale Moon for Linux
website. So, as a result, I have never obtained a "bad" download.

Since this thread, & the other, I can "see" this on the Windows end too.
What really brought this to my attention, more so, is with FF 62.0.2, where the issue is more apparent to me, then in other browsers.

Now what I see, is nowhere near 2 seconds, not even that "slight" delay as seen in the other thread.

I believe what Thomas0038 posted is going in the correct direction.
Similarly I came across, [Invalid] NoScript Breaks Window Sizing.

Rather than let this issue simply "die on the vine" for lack of attention, I feel that I must make one more comment. I have dropped Pale Moon 28 and gone back to version 27.9.4, which still works wonderfully (and WITHOUT the crazy start-up bug), but I do realize that it is not receiving any "support" of any kind. Thus, the ever-changing internet plus the danger of some "new" security flaw will one day render it less than ideal.
That being the case, I was very discouraged to discover that this bug (or "issue" if you prefer) has never yet been posted at "https://github.com/MoonchildProductions/UXP/issues/". Since I still keep hoping that someone somewhere will discover how to fix the bug, I can't help but figure that Moonchild and others just don't want to take it seriously. I sincerely hope that I have reached a mistaken conclusion.
I do keep watching for new releases, and if this would be eventually fixed, I would gladly return to the new UXP version in a minute. I just thought I'd let you know.

This "bug" exists in Tycho. I have seen it many times.

I appreciate your interest, yami_, but this particular "bug" does NOT exist in Tycho (or ANY previous version of Pale Moon that I know of). In previous versions of Pale Moon, a user could simply edit (after closing Pale Moon) the "xulstore.json" file in their home directory, and "Problem solved". Pale Moon 28 (using UXP) is a very different animal; you can "edit" that same file all you want to, and it will simply IGNORE your changes and revert to its previous behavior. Any geometry or start-up problems in previous versions of Pale Moon were "child's play" compared to this. In addition, from what others have written about this bug, it seems to be more serious in the Linux version. If you'll re-read the previous posts, you'll see that it's been reported to exist in the latest Linux version of SeaMonkey, as well. So it seems that this is a UXP-specific issue.

You have to understand that this is a non-breaking issue and as such is very low priority compared to other issues. You having gone back to 27 and therefore removing our reporter's environment from the testbed for any potential fixes bumps it down further.
I also don't think this is anything new, just more pronounced in v28 because the code base does a lot more thing asynchronously on startup -- the frame may render sooner as a result, but at a size that needs to be corrected. Your specific "slit" environment may also report different desktop metrics on purpose that takes Pale Moon some time to figure out and correct when realizing it is not actually full-window.