PM4Linux and oxygen-gtk: a better solution

[access2godzilla]

Scratch that (see above).

However, I did get an older version to work, Debian's version 1.2.4.

[Antonius32]

The newest version is oxygen-gtk2-v1.4.5.

I would like to try it out, but when I click System settings > (Application) Appearance > GTK > Get new themes > Install a local theme, then select the .tar.gz file and click "OK", the "Install theme" button is grayed out. I don't know how to change this; do you have any suggestions?

[Antonius32]

However, I did get an older version to work, Debian's version 1.2.4.

That's great! However, it would be even better if the newest version turned out to be compatible with Pale Moon, don't you agree?

[access2godzilla]

It's not a theme in the usual sense, it's a binary component and can't be installed in that way. And BTW 1.4.5 doesn't work too.

Seems as if every version of pm4linux in existence has had this problem, will compile 24.0.2 and see if it persists there.

[Antonius32]

I just installed Firefox ESR (24.6.0) on my system, to see if it has the same problem. Much to my surprise, it runs without a hitch.

[dinosaur]

I just installed Firefox ESR (24.6.0) on my system, to see if it has the same problem. Much to my surprise, it runs without a hitch.

This could be due to the fact that the Azure rendering backend was enabled unconditionally under Linux (it used to be disabled by default) in PM v24.6.2... Try PM v24.6.1 and see if it works the same as FF 24ESR does.

Also, try changing the "layers.acceleration.disabled" setting to true in about:config, and see if it makes a difference with PM 24.6.2.

[access2godzilla]

This could be due to the fact that the Azure rendering backend was enabled unconditionally under Linux.

Seems as if every version of pm4linux in existence has had this problem

even 24.2.2, the very first version released.

At the moment I'm compiling 24.0.2 to check whether that shows any problems. But without diffs/commits, it's really difficult to trace this down.
Edit:now the build process fails for that version (with apparently no errors), which spells the end of my investigations.

Cyansmoker will have to look into this.

[Antonius32]

Also, try changing the "layers.acceleration.disabled" setting to true in about:config, and see if it makes a difference with PM 24.6.2.

I just tried that, but it didn't make any difference. (By the way: you don't have to go to about:config to change this setting.)

now the build process fails for that version (with apparently no errors), which spells the end of my investigations.

Thank you for taking the trouble of compiling old versions of Pale Moon, in order to find a solution for this problem. Too bad it didn't work out, so far.

Hopefully cyansmoker has some new insights on the matter, and If there's anything I can do to help, just let me know!

[access2godzilla]

A quick question for Moonchild: which FF ESR release is closest to PM 24.1.0(which also crashes with oxygen-gtk)?

[Moonchild]

A quick question for Moonchild: which FF ESR release is closest to PM 24.1.0(which also crashes with oxygen-gtk)?

FF 24.0

[access2godzilla]

Apparently, there are no code changes within PM and FF which would cause this conflict.

Comparing the release notes shows that the version closest to PM 24.1.0 is FF 24.1.0. Comparing the two source trees gives me this (with only those parts that could be of our interest):

Code: Select all

./python/psutil/build/lib.linux-x86_64-2.7/_psutil_linux.so
./python/psutil/build/lib.linux-x86_64-2.7/_psutil_posix.so
./python/psutil/build/temp.linux-x86_64-2.7/psutil/_psutil_linux.o
./python/psutil/build/temp.linux-x86_64-2.7/psutil/_psutil_posix.o
./python/psutil/_psutil_linux.so
./python/psutil/_psutil_posix.so
./gfx/2d/Blur.cpp
./gfx/cairo/libpixman/src/Makefile.in
./gfx/cairo/libpixman/src/pixman-fast-path.c
./gfx/thebes/gfxPlatform.cpp
./gfx/thebes/gfxWindowsPlatform.cpp

• /gfx/* doesn't seem to have any changes that could possibly cause this bug. /python/psutil/*(posix|linux)* seem to be missing from the Pale Moon source tree.
• The only strange thing I noticed that FF needed --disable-elf-hack to compile*; PM didn't. The makefiles/configure.* didn't show anything that could be related to this.u
  The copy of FF ESR I compiled didn't crash, OTOH PM did.

Any hints as to where should I look at now?
*: --disable-elf-hack doesn't fix these crashes for PM.

[Antonius32]

Comparing the release notes shows that the version closest to PM 24.1.0 is FF 24.1.0.

To get this straight:

• The first version of Pale Moon that was released for Linux is version 24.2.0 24.2.2.
• The last version of Pale Moon that was not released for Linux is version 24.1.0.
• For testing purposes, you have just built version 24.1.0 for Linux, and it crashes when used together with oxygen-gtk.
• Pale Moon v 24.1.0 was based on Firefox ESR v 24.1.0; the Linux version of Firefox ESR v 24.1.0 does not crash when used together with oxygen-gtk.

Correct?

[access2godzilla]

The first released version was 24.2.2; but anyway the PM source always contained Linux code, just that no one built it before. And you're right, Firefox ESR, even the ones that I built myself, doesn't crash (That eliminates the possibility that the toolchains were responsible.)

I'm really not sure where else the reason behind the crashes could be hiding; unfortunately without the help of Moonchild it would be diffcult to isolate the problem. After all, I am not well versed with the Mozilla codebase.
(It should be noted that that the bug is with oxygen-gtk; just that I'm attempting to do something to reduce its severity. A browser that crashes even before you do something with it doesn't leave people with a good impression. After all, Firefox doesn't do the same.)

[Antonius32]

(...) the PM source always contained Linux code, just that no one built it before. And you're right, Firefox ESR, even the ones that I built myself, doesn't crash (...)

So I assume then, that Firefox for Windows and Firefox for Linux are built from the exact same source code, just like PM4Linux is built from the same source code as Pale Moon for Windows?

A browser that crashes even before you do something with it doesn't leave people with a good impression. After all, Firefox doesn't do the same.

My thoughts exactly. I really think fixing this would benefit Pale Moon's overall reputation.

I'm really not sure where else the reason behind the crashes could be hiding; unfortunately without the help of Moonchild it would be diffcult to isolate the problem.

As you have ruled out the option of the build process being the cause for this, it must be a divergence from Firefox's source code that was decided at some point in time. I hope Moonchild can help narrow down the options, by pointing out the changes (compared to Firefox) that are likely to be related to this issue, and by letting you know the version numbers at which those changes were implemented. Then one by one, the versions preceding those that saw the implementation of such a change could be rebuilt for Linux, to pinpoint the change that's causing this GTK issue...

Of course, that's easier said than done; I wish there was more I could do to help!

[Moonchild]

Without knowing what exactly causes this issue, it's impossible to find a solution.
Since I am by far a Windows developer, I'll have to divert this question to the people who have offered to maintain the Linux port, which involves more than just building and publishing: primarily cyansmoker, also perhaps Nigaikaze, and access2godzilla (when you have time)

[Antonius32]

For what it's worth (you never know), here's the error that shows when Pale Moon crashes:

Code: Select all

###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for operation); 4 requests ago: file /root/Projects/palemoon/Pale-Moon/toolkit/xre/nsX11ErrorHandler.cpp, line 157
###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for operation); 4 requests ago: file /root/Projects/palemoon/Pale-Moon/toolkit/xre/nsX11ErrorHandler.cpp, line 157
Segmentation fault

[Moonchild]

Insufficient resources? Heh, that would mean you run out of VRAM, meaning, in turn, something has a horrible memory leak in that theme.

[Antonius32]

This may also be worth mentioning:

• Pale Moon + oxygen-gtk + newly created profile => Pale Moon is shut down instantly when the user tries to open a drop-down menu.
• Pale Moon + oxygen-gtk + profile with add-ons, a lightweight theme, and personal preferences => Pale Moon runs steadily, but the background for drop-down menus is transparant (or missing, I guess).

I suppose I could single out the add-on or setting that causes this disparity; just let me know if I should.

(If one of my add-ons "fixes" the crash problem by disabling a part of the oxygen-gtk theme that's responsible for drop-down menu backgrounds, then maybe this property could be copied and built into Pale Moon; the only thing left to do then, would be to have Pale Moon replace the missing backgrounds with something else.. Or am simplifying too much now?)

[access2godzilla]

This is the full list of files changed/added/removed in PM 24.1.0 compared to FF 24.1.0: http://pastebin.com/K3S83PiN
Which files cannot possibly be related with these crashes? My earlier attempt to prune the list failed horribly

[Antonius32]

@acces2godzilla: Did you read my previous post? Do you think my suggestion (finding out which add-on causes PM4Linux to not crash) may help get you headed in the right direction? (If not, I'm afraid I can't help you any further.)