OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Internet => Topic started by: Dave Yeo on November 26, 2017, 05:57:19 am

Title: Experimental build of SeaMonkey
Post by: Dave Yeo on November 26, 2017, 05:57:19 am
I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp1.zip)
Optimized for size instead of performance, should fit into memory a bit better and almost as fast. Also optimized for a Pentium M so needs a CPU with SSE2 support.
You could also install it as if it was an RPM, putting everything in @UNIXROOT/usr/lib/seamonkey-2.42.9esr and a copy of seamonkey.exe in @UNIXROOT/usr/bin so it is on the PATH.
Same codebase as the latest release of Firefox. Once dmik releases another version of Firefox, I'll release the usual i686 build and if I ever get some guidance on building an RPM, I'll try to release them as well.
Needs the latest libcx and libc that are now available on netlabs-release RPM repository (I hope).

Note there also seems to be a regression with highmem support, marking xul.dll to load code and data makes SM unstable here on ArcaOS.
Title: Re: Experimental build of SeaMonkey
Post by: Rich Walsh on November 26, 2017, 05:41:27 pm
I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip)

The link does not point at your new build. It is identical to your build of August 17, 2017.

Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 26, 2017, 06:42:51 pm
I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip)

The link does not point at your new build. It is identical to your build of August 17, 2017.

You're right, somehow I uploaded the wrong binary, I'll blame the crappy interface on the phone, though I'm to blame for not double checking. I'll delete the binary and re-upload when I get the chance.

Quote
Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

There's no reason that this can't be installed anywhere, it just also has the option of being installed in @UNIXROOT, which will be needed as Arca Noae eventually wants a RPM, and with all the dependencies, an RPM does make installation easier.
I don't like where development of Mozilla has gone and I did try to upload statically linked binaries for as long as I could, and did things like put sydney audio back in when Bitwise didn't care enough to support sound.
Unluckily, with the direction that Mozilla has gone with Firefox, the need for fixes to the build tools,things like a Python that correctly does the virtual environment thing and the ever increasing list of dependencies and things like NSPR being forked, it has become easier to just follow along with Bitwise and ArcaOS which has become heavily dependent on RPMs.

Quote
These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 27, 2017, 02:06:43 am
Hopefully the link is fixed.
Title: Re: Experimental build of SeaMonkey
Post by: Lars on November 27, 2017, 03:39:07 pm
I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9R2esr.en-US.os2_exp1.zip)

The link does not point at your new build. It is identical to your build of August 17, 2017.

Also, this is OS/2 where the mozapps were specifically designed to be installed wherever the user chooses. Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

These types who go on and on and on about their unyielding hostility to any semblance of a unix directory structure certainly are tiresome (in extremis), but they do have a point. Me, I'll say it only once:  ONU !!!!

It's funny that you say that. I thought it was AN's idea to come up with the splendid "sys", "etc" and "usr" directories.
As arrogant and authoritarian BWW might be: if they pull the plug on application development for OS/2 then ArcaOS is dead in 2 years flat.
Title: Re: Experimental build of SeaMonkey
Post by: Martin Iturbide on November 27, 2017, 05:58:37 pm
Hi Rich.

...Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

I had also presented my dislike of "Filesystem Hierarchy Standard (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)" many times in the past. Even some groups of the Unix world dislike it. But on our case (The OS/2 platform) I think that the issue was that we became dependent of many Linux ports libraries and even that everything can be reorganized on a better structure it was very difficult to maintain a different layout only for OS/2 because of the lack of resources we have on this platform.

We had a lot of DLL versioning issues and RPM was a good solution to keep all that updated, but it came with a cost. It was to much of chore to have RPM customized to have a different FHS on OS/2. So for me it was to "suck it up" with FHS or try to find resources that wanted to maintain a customized RPM version only for OS/2 and that verifies that every ported/updated DLL works on that new structure.

Regards 
Title: Re: Experimental build of SeaMonkey
Post by: xynixme on November 27, 2017, 08:42:44 pm
...Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

I had also presented my dislike of "Filesystem Hierarchy Standard (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)" many times in the past. Even some groups of the Unix world dislike it.

RPM was a good solution to keep all that updated, but it came with a cost.

</silence>
If the number of lines of output exceeds 100, then using STDOUT instead of STDERR hardly requires resources. Of course there are more optional ways to OS/2'ify software. Icon, installer, documented data file search strategies not assuming an @Unixroot, deleting useless files, avoided useless requirements of requirements (like a HUNSPEL0.DLL without any installed dictionary), and so on.

I'll try to care less, but does a RPM release actually manage e.g .the lxLite package, including all documentation files, of eCS 2.x?
<silence>
Title: Re: Experimental build of SeaMonkey
Post by: roberto on November 28, 2017, 04:10:12 pm
Hopefully the link is fixed.
Well, the link does not work for me. ??
saludos
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 28, 2017, 05:07:27 pm
What about if you start at https://bitbucket.org/dryeo/dry-comm-esr31/downloads/ (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/)
Title: Re: Experimental build of SeaMonkey
Post by: R.M. Klippstein on November 28, 2017, 07:12:37 pm
Hi Dave , latest link doesn't work here also. The Inet has been really slow and unrelieable her lately -- don't know what gives!

klipp
Title: Re: Experimental build of SeaMonkey
Post by: Andreas Schnellbacher on November 28, 2017, 08:29:30 pm
latest link doesn't work here also.
Remove the 'R2' from the filename.
Title: Re: Experimental build of SeaMonkey
Post by: roberto on November 28, 2017, 08:41:46 pm
I have not had problems downloading now.
I tell you my tests, they have been executing it for the first time it seemed that I was not doing anything. I executed it again, and a first window appeared, a second, I do not recieve if third and it closed. With seamonkey-2.42.9esr.en-US.os2_exp1
What I have observed is that if I want to run firefox45.9, first I have to run firefox45.5 and close it. Then I can open firefox45.9 without problems. In fact, after I closed firefox45.9, I was able to execute it from a folder that was not in libpath. Although it may be that even if it has booted from a folder that is not in the libpath, it may have loaded the xul.dll that is in libptah. I do not.
The seamonkey generate a trp file if you need.
saludos
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 28, 2017, 09:36:04 pm
Hi Roberto,
You shouldn't have xul.dll in your LIBPATH. Usually SeaMonkey (and Firefox and Thunderbird) look in their program directory for their DLLs including xul.dll.
Now they also look to see if the executable (seamonkey.exe, firefox.exe) is installed in \usr\bin, in which case they will look in \usr\lib\@MOZ_APP_UA_VERSION where MOZ_APP_UA_VERSION currently equals firefox-45.9.0 or seamonkey-2.42.9esr.
The various xul.dll are not compatible with each other, though they are close enough that they will seem to work until you do something like open their options/settings.
Wouldn't hurt to see your trp file and any popuplog.os2 entries after you fix any LIBPATH issues.
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on November 28, 2017, 10:03:49 pm
What about if you start at https://bitbucket.org/dryeo/dry-comm-esr31/downloads/ (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/)
Rendering of this page could be a problem for some OS/2 web browsers. So it needs no jump to the rendering problems that still exist with this build. It's not Dave's fault and shows up in the "latest" Bitwise Firefucks builds. A side effect introduced with switching to different libraries that cannot longer scale gif or jpeg image files correctly? Pictures: the first one shows Seamonkey 2.35 (from Feb 2016) the second the recent build (Nov 2017) - especially for this post with the same bunch of DLL hell. A HUGE diamond improvement in every menu that uses the diamond markers. Best instruction for installation I can give: del README.OS2. The content would fit in one sentence: "Please don't readme, thou shalt praise bitwise coding gods for their rpm/yum fork." Sceptics who cannot follow my command should read this document in reverse order.
Title: Re: Experimental build of SeaMonkey
Post by: roberto on November 28, 2017, 10:28:24 pm
My libpath in config.sys:
LIBPATH=.;C:\usr\local\lib;C:\usr\lib;C:\usr\lib\unixroot\usr\lib\firefox-45.9.0;C:\PROGRAMS\NETSCAPE\PROGRAM;C:\SYS\DLL;etc etc but not the folder.
In this libpath I have the xull.dll modify with highmen
but running this other firefox45.9 in a folder, you can see the trp, because after send me previous message hang with this trp.
In popup.os2 i have not any about firefox.
You can see that is run in d:\util2017test\....
Do you want me to include this folder in libpath? and wait for it to crack, and take out the trp?
saludos

Title: Re: Experimental build of SeaMonkey
Post by: Roderick Klein on November 28, 2017, 11:15:58 pm
I've uploaded an experimental build of SeaMonkey 2.42.9ESR, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp1.zip)
Optimized for size instead of performance, should fit into memory a bit better and almost as fast. Also optimized for a Pentium M so needs a CPU with SSE2 support.
You could also install it as if it was an RPM, putting everything in @UNIXROOT/usr/lib/seamonkey-2.42.9esr and a copy of seamonkey.exe in @UNIXROOT/usr/bin so it is on the PATH.
Same codebase as the latest release of Firefox. Once dmik releases another version of Firefox, I'll release the usual i686 build and if I ever get some guidance on building an RPM, I'll try to release them as well.
Needs the latest libcx and libc that are now available on netlabs-release RPM repository (I hope).

Note there also seems to be a regression with highmem support, marking xul.dll to load code and data makes SM unstable here on ArcaOS.

In my experience only load the code segments high, not the data segments!

I am running Firefox, Thunderbird and Open Office next to each other without an issue. Without loading the DLL's in high memory it toasts my system within a few minutes.

Roderick
Title: Re: Experimental build of SeaMonkey
Post by: Andreas Schnellbacher on November 29, 2017, 02:05:38 am
Note there also seems to be a regression with highmem support, marking xul.dll to load code and data makes SM unstable here on ArcaOS.
In my experience only load the code segments high, not the data segments!
Dmitriy's comments (https://github.com/bitwiseworks/mozilla-os2/issues/250#issuecomment-347690062) explain what Dave has stated.

(I myself haven't tested Dave's build yet. About loading data segments high: It depends. Unfortunately that would be more effective than code segments in the respect of saving low shared memory.)
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 29, 2017, 02:27:30 am
Note there also seems to be a regression with highmem support, marking xul.dll to load code and data makes SM unstable here on ArcaOS.
In my experience only load the code segments high, not the data segments!
Dmitriy's comments (https://github.com/bitwiseworks/mozilla-os2/issues/250#issuecomment-347690062) explain what Dave has stated.

(I myself haven't tested Dave's build yet. About loading data segments high: It depends. Unfortunately that would be more effective than code segments in the respect of saving low shared memory.)

I think it is a different issue that Dmitriy is talking about, namely dynamically allocating memory high.
Here SM 2.35 is stable with the DLLs marked to load both data and code high and currently I have Thunderbird-2.4.8 DLLs marked to load high while SeaMonkeys are not marked and the system is fairly stable, at least for a day or two.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 29, 2017, 02:38:29 am
My libpath in config.sys:
LIBPATH=.;C:\usr\local\lib;C:\usr\lib;C:\usr\lib\unixroot\usr\lib\firefox-45.9.0;C:\PROGRAMS\NETSCAPE\PROGRAM;C:\SYS\DLL;etc etc but not the folder.
In this libpath I have the xull.dll modify with highmen
but running this other firefox45.9 in a folder, you can see the trp, because after send me previous message hang with this trp.
In popup.os2 i have not any about firefox.
You can see that is run in d:\util2017test\....
Do you want me to include this folder in libpath? and wait for it to crack, and take out the trp?
saludos

You should remove C:\usr\lib\unixroot\usr\lib\firefox-45.9.0 from your LIBPATH and run C:\usr\lib\unixroot\usr\lib\firefox-45.9.0\firefox.exe Any program objects should also use this as the working directory.
Title: Re: Experimental build of SeaMonkey
Post by: Andreas Schnellbacher on November 29, 2017, 02:44:48 am
I think it is a different issue that Dmitriy is talking about, namely dynamically allocating memory high.
OK, with your explanation I see the difference, but I don't fully understand memory allocation in C.

Here SM 2.35 is stable with the DLLs marked to load both data and code high
Here as well.
Title: Re: Experimental build of SeaMonkey
Post by: xynixme on November 29, 2017, 05:15:41 pm
In this libpath I have the xull.dll modify with highmen

</silence>
FWIW: are you using SET LIBPATHSTRICT=T and e.g. SET BEGINLIBPATH=y:\TEST;x:\yz\SEAMONKEY as (hidden) WPS settings for your SM test objects?

If so, then you may not be using the expected LIBPATH directory which contains a patched XUL.DLL.
If not, then you could consider to start using those settings to make sure that FF/SM will use expected DLLs, like a y:\TEST\XUL.DLL or a JPEG.DLL in SM's directory.
<silence>
Title: Re: Experimental build of SeaMonkey
Post by: roberto on November 29, 2017, 05:26:50 pm
You should remove C:\usr\lib\unixroot\usr\lib\firefox-45.9.0 from your LIBPATH and run C:\usr\lib\unixroot\usr\lib\firefox-45.9.0\firefox.exe Any program objects should also use this as the working directory.
Finally I have been able to start the seamonkey.
I have removed everything from the libpath. Both in config.sys and in usr \ lib ..
In firefox45.9 I started it from any folder. Unzip and execute, perfect.
But the seamonkey failed again and again, with the path without the path and in usr \ lib. Delete everything in d:\home\seamonkey, copy the profiles from firefox to seamonquey and everything perfect, now I execute it from any folder.
Do not copy the thunderbird, because it's not my idea to use the seamonkey.
The videos look just as bad.
saludos
regards
Title: Re: Experimental build of SeaMonkey
Post by: Pete on November 29, 2017, 05:33:21 pm
Hi Dave

This build works about the same as the previous build: no video playback - cannot even load youtube pages completely. Less of a problem with cpus peaking when using the browser but email/newsgroups causes cpu peaking.

Something to point out from the Readme:-

"The list of RPM packages required by Firefox is
   contained in a file named RPM_REQUIREMENTS inside the ZIP archive."

So it is now necessary to download and unzip the Firefox package to read that readme file to discover what support files are required for Seamonkey!


Regards

Pete

Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 29, 2017, 06:05:08 pm
Something to point out from the Readme:-

"The list of RPM packages required by Firefox is
   contained in a file named RPM_REQUIREMENTS inside the ZIP archive."

So it is now necessary to download and unzip the Firefox package to read that readme file to discover what support files are required for Seamonkey!

Missed that. If someone wants to send me the file, I can add it to the zip.
At some point hopefully someone will tell me how to create a RPM and then I can generate it myself.

As for the high CPU and failing youtube, hopefully Bitwise will figure it out as it seems to be a problem with the JavaScript engine.
Title: Re: Experimental build of SeaMonkey
Post by: Pete on November 29, 2017, 06:39:01 pm
Hi Dave

Forgot to add that this build of Seamonkey often hangs when starting and can take 3 or 4 attempts to actually get it running.

Maybe I do not have the latest something "lib-nixy" installed but ANPM tells me that everything is up to date...


Regards

Pete


Title: Re: Experimental build of SeaMonkey
Post by: roberto on November 29, 2017, 08:01:35 pm
As for the high CPU and failing youtube, hopefully Bitwise will figure it out as it seems to be a problem with the JavaScript engine.
I disagree with this. Today in firefox 45.9. I have been able to watch videos on YouTube as always, even the same mistakes as in previous versions. But I have not been able to repeat it, for now.
When I created a new profile in seamonkey, I stopped booting. It gives me the feeling that the seamonkey, fails in the creation of the profiles, and that's why I could not execute it.
I even think that the seamonkey, I modified the profile of firefox, and that's why I could see the videos well.
saludos
Title: Re: Experimental build of SeaMonkey
Post by: Dariusz Piatkowski on November 30, 2017, 04:06:09 am
Dave!

Something to point out from the Readme:-

"The list of RPM packages required by Firefox is
   contained in a file named RPM_REQUIREMENTS inside the ZIP archive."

So it is now necessary to download and unzip the Firefox package to read that readme file to discover what support files are required for Seamonkey!

Missed that. If someone wants to send me the file, I can add it to the zip....

Attached to the response...taken from the 7z build of Firefox.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 30, 2017, 05:13:06 am
As for the high CPU and failing youtube, hopefully Bitwise will figure it out as it seems to be a problem with the JavaScript engine.
I disagree with this. Today in firefox 45.9. I have been able to watch videos on YouTube as always, even the same mistakes as in previous versions. But I have not been able to repeat it, for now.
When I created a new profile in seamonkey, I stopped booting. It gives me the feeling that the seamonkey, fails in the creation of the profiles, and that's why I could not execute it.
I even think that the seamonkey, I modified the profile of firefox, and that's why I could see the videos well.
saludos

Just tested creating a brand new profile, seemed fine. The big difference with SM from FF is that SeaMonkey installs some extensions by default. Chatzilla for one seems to create a lot of CPU usage and should probably be disabled, as do some others such as adblockplus on Firefox and perhaps SeaMonkey.
Here the only time that SeaMonkey won't start is if I already have Thunderbird running. The other way works fine.
For both you and Pete, does starting in safe-mode help, both starting and playing youtube videos?
Code: [Select]
seamonkey.exe -safe-mode
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on November 30, 2017, 05:14:02 am
Attached to the response...taken from the 7z build of Firefox.

Thanks
Title: Re: Experimental build of SeaMonkey
Post by: roberto on November 30, 2017, 03:59:42 pm
For both you and Pete, does starting in safe-mode help, both starting and playing youtube videos?
Code: [Select]
seamonkey.exe -safe-mode
This does not improve anything in my case.

When I create a new profile in seamonkey, 1,2,3, ...
If I modify in firefox \ profiles.ini
StartWithLastProfile=1    replace by 1, 2, or 3 ...
 This allows me to run only one session in firefox 45.9 with the videos ok. I understand that this session does not close well, but that I have to kill it. It does not allow me to repeat it again. Unless you create a new profile ....
saludos
Title: Re: Experimental build of SeaMonkey
Post by: Pete on November 30, 2017, 08:56:32 pm
Hi Dave

No starting with /safe-mode makes no difference to Seamonkeys ability to play youtube videos or even load the page fully - when selecting a vid only the playback window with the Menu button, Play button next to text YouTube and search entry field appear on the page; nothing else at all.

I have checked the RPM_REQUIREMENTS and have everything up to date with the exceptions of:-

1] bww-resources-rpm-1.1.0-3.oc00.noarch - I think this is a bitwise icons update that I may get around to installing but should not be necessary to run an app

2] libc-devel-0.6.6-35.oc00.i686 - Why is this needed? - No plans on development using these tools myself. Surely it is not needed to run apps?


Regards

Pete
Title: Re: Experimental build of SeaMonkey
Post by: David McKenna on November 30, 2017, 09:25:57 pm
 I'm also seeing strange behavior with SeaMonkey and YouTube. If I go to the main YouTube page (www.youtube.com) everything looks OK, click on any video, the video page comes up with all comments and right side links like normal, but the video has a message: 'An error occurred. Please try again later.' and won't play. Then hit the 'reload' icon, get the video window, the YouTube search bar at the top and nothing else, but a 'waiting for...' message in the status bar. Now if I type 'Warpstock' in the YouTube search bar, I get a page with a bunch of videos from various Warpstocks and all of them play! So my guess is that videos with advertisements are somehow exposing a problem in SeaMonkey (since the Warpstock videos don't have any - somewhat unusual). Maybe can't handle some kind of network re-direction?

  Similar situation with Firefox, but after installing the H264ify add-on in Firefox none of these problems exist. When I get some time, I'll run Wireshark with and without H264ify and see if anything interesting crops up....
Title: Re: Experimental build of SeaMonkey
Post by: Dariusz Piatkowski on December 01, 2017, 02:51:57 am
Hi Pete,

...
2] libc-devel-0.6.6-35.oc00.i686 - Why is this needed? - No plans on development using these tools myself. Surely it is not needed to run apps?...

Like you, I have no current DEV plans, so I ignored this install, my FF 45.9 works fine here. Just to re-iterate, this FF only experience...
Title: Re: Experimental build of SeaMonkey
Post by: Pete on December 01, 2017, 03:01:53 am
Hi

@Dariusz
Thanks for confirming package is not required for Firefox; I think that also applies to Seamonkey.

@David
As I have now managed to get some videos playing I suspect you may have a valid point about "videos  with advertisements are somehow exposing a problem in SeaMonkey". How do I tell if the video should play an advert though?


Regards

Pete
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 01, 2017, 03:59:41 am
Here's h264ify converted for SeaMonkey. It installed here but it needs testing on Youtube.
Drag'n'drop on the add-ons page.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 01, 2017, 05:03:35 am
BTW, a site worth bookmarking for SeaMonkey users, http://addonconverter.fotokraina.com/ (http://addonconverter.fotokraina.com/).
Which is what I used to convert h264ify
Title: Re: Experimental build of SeaMonkey
Post by: David McKenna on December 01, 2017, 12:28:19 pm
 Hi Pete,

  The only way I have to check for an advertisement is try the same video with a windows install (I use my laptop). Obviously I haven't seen them all, but the ones I get an ad in Windows don't play in OS/2. So far, all non-ad videos I've run across do play in OS/2. But H264ify seems to play them all (so far..) including ads.
Title: Re: Experimental build of SeaMonkey
Post by: David McKenna on December 01, 2017, 12:34:01 pm
Hi Dave,

  Thanks for the H264ify converter for SeaMonkey! Where did you get the XPI file? Was going to do the conversion myself, but couldn't locate where to download the file - the website wanted to install directly, but wouldn't allow doing that with SeaMonkey...
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 01, 2017, 12:50:32 pm
BTW, a site worth bookmarking for SeaMonkey users, http://addonconverter.fotokraina.com/ (http://addonconverter.fotokraina.com/).
Which is what I used to convert h264ify
For users it should be easier to use the AMO add-on.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 01, 2017, 04:29:36 pm
Hi Dave,

  Thanks for the H264ify converter for SeaMonkey! Where did you get the XPI file? Was going to do the conversion myself, but couldn't locate where to download the file - the website wanted to install directly, but wouldn't allow doing that with SeaMonkey...

I just searched for it and got a page at Mozilla add-ons which listed older versions.
Unluckily with the changes at Mozilla and them kicking SeaMonkey and Thunderbird off their infrastructure, sooner or later it is going to get hard to find some of these extensions.
Title: Re: Experimental build of SeaMonkey
Post by: Pete on December 02, 2017, 12:13:15 am
Hi Dave

Thanks for the h264ify package - seems to have resolved most playback problems here in that all videos I have tried played. Most stop with the buffering indicator onscreen after a short period but can often be nudged on a little and then play.


Regards

Pete
Title: Re: Experimental build of SeaMonkey
Post by: David McKenna on December 02, 2017, 01:04:03 am
 Pete!

  Yes, I see that buffering indicator issue too.... weird...
Title: Re: Experimental build of SeaMonkey
Post by: roberto on December 02, 2017, 10:44:20 am
I have bad news with the H264 .., in my case the whole system hangs up. For a moment it seems that it does not show the error in videos, but soon after it takes place.
I think maybe it could be because I'm not using the arca sound drivers, but some older version.
Would someone tell me, how can I make a copy of the firefox password, to pass them from one profile to another?
saludos
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 02, 2017, 02:06:31 pm
I don't know exactly the date but YT changed their player in October. This h264ify is not a real solution because it still keeps the ytplayer and does not replace ytplayer by internal mechanism. It only disables the VP8/9 capability reporting - not a real extension but more restrictions. Unfortunately with the YT changes older addons (HTML5 Video Everywhere!) that provided a workaround in those situations can no longer be utilised. Newer versions switched to WebExtensions (Fx57) which is not supported by seamonkey. A possible solution could be to take the Jewtube filter changes from the newer version and adopt them in a compatible add-on version. The users should better a ask the author of this particular extension. This side issues become boring by time.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 19, 2017, 04:15:33 am
I think I found the problem with playing VP9 YouTube videos, please disable h264ify and test this build, https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp2.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp2.zip). Seems to work here though not the smoothest experience on my old computer. No special optimizing, built to target i686 with GCC 510.
Title: Re: Experimental build of SeaMonkey
Post by: David McKenna on December 19, 2017, 12:14:53 pm
Dave,

  Thanks! Yes, that seems to work well, what was it?
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 19, 2017, 04:27:37 pm
Seems to be something missing in my build environment on ArcaOS. What exactly, I'm not sure yet but the only difference was that I built this using my older build environment on eCS2.1. Same UNIXROOT, same source tree, but a lot more stuff installed on the old install.
This is after finding a 6 month old build that worked and spending a lot of time trying to find what changed to break SM :(
The good news is that Telus finally lit up their new cell tower and I'm using that for Internet so I can test this stuff.
Title: Re: Experimental build of SeaMonkey
Post by: Dariusz Piatkowski on December 19, 2017, 10:08:33 pm
I just hope Dave that whatever root cause you identify will be addressed in the FF build as well...
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 19, 2017, 10:33:32 pm
The Firefox build seems to play VP9 fine.
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 19, 2017, 11:38:37 pm
The Firefox build seems to play VP9 fine.
Simply kick out the "distribution\extension" sub-directory before running seamonkey.exe the first time. I don't know exactly which one causes the high process load. Perhaps DOM inspector, chatzilla or/and lightning. I/O load is approximately 100 times higher than Netscape downloading the same files (w/o caching). But that's usual for all later builds.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 20, 2017, 12:38:56 am
Chatzilla seems to cause the high CPU load. Why I don't know as it hasn't changed in a while.
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 20, 2017, 01:14:32 am
Chatzilla seems to cause the high CPU load. Why I don't know as it hasn't changed in a while.
A lot of additional stuff hasn't changed for a while. But changes in the build system and newer class dependencies can easily break everything. Now there's no complete theme left that fully works for Seamonkey. For some components even the default is broken for more than 10 years.
Title: Re: Experimental build of SeaMonkey
Post by: Dariusz Piatkowski on December 20, 2017, 05:07:08 am
The Firefox build seems to play VP9 fine.

Dave, then you are lucky!!!

My FF release (the official RPM one) will not play w/o that H264 extension.
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 20, 2017, 12:53:41 pm
Vp9 playback works without this so-called extension. Check the UA reporting setting also. At least to some degree. There are other issues with ytplayer - non-working volume control and mute. Full-screen switch (F11) is broken since years.
Title: Re: Experimental build of SeaMonkey
Post by: Andy Willis on December 20, 2017, 03:04:43 pm
I have only tried one video that I had had issues with and it worked.  However, the menu bar is changed.  The menu items appear to be highlighted (for want of a better term) such that I just see grey boxes unless I run the mouse over them and then I can see the words.

Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 20, 2017, 04:19:27 pm
I have only tried one video that I had had issues with and it worked.  However, the menu bar is changed.  The menu items appear to be highlighted (for want of a better term) such that I just see grey boxes unless I run the mouse over them and then I can see the words.

That's strange. Do you have layout.frame_rate set to something besides zero? I see something similar in the profile manager where the person icon doesn't display until I mouse over them but once my profile loads, things are fine.
I did revert menu.css to the version from 38ESR to try to fix the menu check icon, see https://github.com/bitwiseworks/mozilla-os2/issues/252
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 20, 2017, 04:24:26 pm
I have only tried one video that I had had issues with and it worked.  However, the menu bar is changed.  The menu items appear to be highlighted (for want of a better term) such that I just see grey boxes unless I run the mouse over them and then I can see the words.
The build is marked as experimental by Dave. So I have no complaints. There are minor issues in packaging that are resulting from the build system. And GCC 5.1 wants up to 20% more binary footprint.

Some overrides for the standard theme make no sense, so you can replace in sub-directory "extensions" with the attached file.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 20, 2017, 04:27:41 pm
Vp9 playback works without this so-called extension. Check the UA reporting setting also. At least to some degree. There are other issues with ytplayer - non-working volume control and mute. Full-screen switch (F11) is broken since years.

The F11 thing was fixed a few months back by Bitwise and works fine here, same with the full screen switch in ytplayer.
You are right about the volume control not working, at least with KAI_AUTOMODE=DART which is the default under ArcaOS. Have to test UNIAUD.
I see that at least you seem to have it localized.
edit,
With KAI_AUTOMODE=UNIAUD the volume is stuck on mute here.
Title: Re: Experimental build of SeaMonkey
Post by: roberto on December 20, 2017, 05:25:10 pm
Well, the creation of a new profile continues to fail me. It only works for me if I use an FF profile. Usually all very well, you can even print directly. The videos now generate a new problem, the sound continues and the image stops.
saludos
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 20, 2017, 05:57:10 pm
The F11 thing was fixed a few months back by Bitwise and works fine here, same with the full screen switch in ytplayer.
Perhaps under special arrangements but not generally. Using F11 with this particular build it tries to fake some kind of full screen area usage. In fact the current code only removes the window decorations at maximises the parent window class. Switching back with F11 doesn't restore all decorations - only the titlebar but no frame. I don't want to list all issues with PM and C/C++ pointer insanity here. Drag and Drop is the best way to kill the whole application - a nice feature for small systems - no need for a process killer app - a small animated gif works sometimes more reliable.  8)Unfortunately automated interactive testing for several hours is not doable at all.

Quote
You are right about the volume control not working, at least with KAI_AUTOMODE=DART which is the default
Inside the context of JS code it works, but it doesn't control the volume for the used audio device.

Quote
I see that at least you seem to have it localized.
No, only poorly soldered. I don't know from which source your lightning 4.7.9 came from. The last release in this line was version 4.7.8. So the existing german xpi should already work.
Title: Re: Experimental build of SeaMonkey
Post by: roberto on December 20, 2017, 08:58:10 pm
In mail config in *disk space* fail with error.
saludos
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 20, 2017, 11:00:06 pm
@Roberto
You mean the item about when to compact? Do you have much free space?
Also about your profile creation problem, can you compare the SM created profile to the FF one? New profile works fine here.
Also perhaps start seamonkey like
Code: [Select]
seamonkey 2>&1 | tee seamonkey.logand see if anything interesting gets written in the log when creating a profile.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 21, 2017, 05:41:50 am
The F11 thing was fixed a few months back by Bitwise and works fine here, same with the full screen switch in ytplayer.
Perhaps under special arrangements but not generally. Using F11 with this particular build it tries to fake some kind of full screen area usage. In fact the current code only removes the window decorations at maximises the parent window class. Switching back with F11 doesn't restore all decorations - only the titlebar but no frame. I don't want to list all issues with PM and C/C++ pointer insanity here. Drag and Drop is the best way to kill the whole application - a nice feature for small systems - no need for a process killer app - a small animated gif works sometimes more reliable.  8)Unfortunately automated interactive testing for several hours is not doable at all.

Interesting, full screen has consistently worked the same here since Netscape 4.61 with the exception of 45.5 where it was broken.
Drag and drop usually works fine here though there has been an issue for the longest time where if you do it too quick, the browser crashes. Perhaps on faster hardware, too quick isn't so quick anymore.

Quote
You are right about the volume control not working, at least with KAI_AUTOMODE=DART which is the default
Inside the context of JS code it works, but it doesn't control the volume for the used audio device.
[\quote]

Doesn't work on other video sites such as the NFB (National Film Board of Canada) site. Still better then Linux where I couldn't get any sound out of SM and ended up using Chromium.

Quote
I see that at least you seem to have it localized.
No, only poorly soldered. I don't know from which source your lightning 4.7.9 came from. The last release in this line was version 4.7.8. So the existing german xpi should already work.
[/quote]

The lightning source was in the tree when I downloaded the source.
Title: Re: Experimental build of SeaMonkey
Post by: Lars on December 21, 2017, 01:27:10 pm

Interesting, full screen has consistently worked the same here since Netscape 4.61 with the exception of 45.5 where it was broken.
Drag and drop usually works fine here though there has been an issue for the longest time where if you do it too quick, the browser crashes. Perhaps on faster hardware, too quick isn't so quick anymore.


I doubt that this has anything to do with speed. I would think that this depends on the windows that are crossed when you drag stuff. This sounds much like a bug in a window procedure getting a notification that something is dragged across it and then accessing the dnd info in the wrong way, eventually crashing either the drag source or drag target application. It's also possible that the crossed window does everything ok but the drag source reacts in the wrong way when the crossed window establishes some handshaking with the drag source /notifies the drag source.
I would not be surprised if the error still exists. You just have not reproduced the right scenario for it to happen.
Title: Re: Experimental build of SeaMonkey
Post by: Andy Willis on December 21, 2017, 02:32:48 pm
I have only tried one video that I had had issues with and it worked.  However, the menu bar is changed.  The menu items appear to be highlighted (for want of a better term) such that I just see grey boxes unless I run the mouse over them and then I can see the words.

That's strange. Do you have layout.frame_rate set to something besides zero? I see something similar in the profile manager where the person icon doesn't display until I mouse over them but once my profile loads, things are fine.
I did revert menu.css to the version from 38ESR to try to fix the menu check icon, see https://github.com/bitwiseworks/mozilla-os2/issues/252
I use layout_frame_rate set to 59 or 60 (have used both with the same results with the menu bar).  The menu items are only visible while the mouse hovers over the specific item and then it goes grey again after removing the mouse (unless the menu bar is dropped down and then it stays while the menu is open).
When I get a chance, I'll look at the menu.css and see if something stands out.
Title: Re: Experimental build of SeaMonkey
Post by: roberto on December 21, 2017, 03:20:37 pm
You mean the item about when to compact?
Nothing with compact
Quote
Do you have much free space?
Yes, I have it
Quote

Also about your profile creation problem, can you compare the SM created profile to the FF one? New profile works fine here.
Need more time for this, only if it is necessary.
Quote
Also perhaps start seamonkey like
Code: [Select]
seamonkey 2>&1 | tee seamonkey.log[\code]
and see if anything interesting gets written in the log when creating a profile.
[/quote]
I attached the file seamonkey.log and the corresponding trp file.
saludos
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 22, 2017, 02:10:00 am
Interesting, full screen has consistently worked the same here since Netscape 4.61 with the exception of 45.5 where it was broken.
So which method you're using to switch Netscape to "full screen". F11 wasn't implemented there...

F11 Full screen has the following issues now:
* lost focus
* no redraw (until manually switched by using the window list")
* no restore after switching back using F11 instead fixed window size without borders with same redraw issues
* total PS madness

I cross-checked and it can be reproduced.

Also the last Windows (2.49) release has a related issue. While using the browser window in F11 full screen the YT player cannot maximise to real full screen (for video playback).

The real full screen (for video playback) never worked under OS/2. Instead the same non-working F11 method is invoked.
Title: Re: Experimental build of SeaMonkey
Post by: Andy Willis on December 22, 2017, 05:14:00 am
I have only tried one video that I had had issues with and it worked.  However, the menu bar is changed.  The menu items appear to be highlighted (for want of a better term) such that I just see grey boxes unless I run the mouse over them and then I can see the words.

That's strange. Do you have layout.frame_rate set to something besides zero? I see something similar in the profile manager where the person icon doesn't display until I mouse over them but once my profile loads, things are fine.
I did revert menu.css to the version from 38ESR to try to fix the menu check icon, see https://github.com/bitwiseworks/mozilla-os2/issues/252
I use layout_frame_rate set to 59 or 60 (have used both with the same results with the menu bar).  The menu items are only visible while the mouse hovers over the specific item and then it goes grey again after removing the mouse (unless the menu bar is dropped down and then it stays while the menu is open).
When I get a chance, I'll look at the menu.css and see if something stands out.
Somehow, I had gotten switched to Metal Lion SeaMonkey theme... I don't remember doing it but must have been playing with it at some point, Seamonkey Default Theme works fine.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 22, 2017, 06:13:09 am
It all works fine here though it does have the same problem as Windows in not going to full screen from kiosk (F11) mode. Here's screenshots of the full screen video I get when clicking the full screen thingie at the bottom right of the video and the F11 results. Both restore fine to a window though restoring from F11 leaves the page somewhat up the page so I have to scroll down to get to where I was.
I seem to have mis-remembered about Netscape supporting F11 but current SM F11 full screen looks almost the same as doing it with SM 1.19.

ps had to resize the images to half size, the thing at the bottom of the fullscreen shot is the noscript bar
Title: Re: Experimental build of SeaMonkey
Post by: ak120 on December 22, 2017, 02:52:39 pm
It all works fine here though it does have the same problem as Windows in not going to full screen from kiosk (F11) mode.
F11 full screen worked with your sm 2.7.2 build. Later it became broken in several ways.

Quote
Here's screenshots of the full screen video I get when clicking the full screen thingie at the bottom right of the video and the F11 results.
The picture doesn't show a full screen for video playback. I cannot recognise what's on the bottom there? Also the dimensions are strange for full screen.

Quote
Both restore fine to a window though restoring from F11 leaves the page somewhat up the page so I have to scroll down to get to where I was.
The behaviour is not consistent. Using a sized window and using F11 twice seems to work reliably. But starting with a maximised window and using F11 only restores to the defined size not to the maximised window. With Seamonkey 2.7.2 it's acceptable, only new started AVIO applications should causes redraw timing problems. With external NSPR in latest builds it's totally broken. No switch back for the window for video playback from forced foreground to the normal behavour seems to be the most annoying issue. So it's child windows are in the background and quite unusable.

Quote
I seem to have mis-remembered about Netscape supporting F11 but current SM F11 full screen looks almost the same as doing it with SM 1.19.
You can run netscape with the parameter -k to use the kiosk mode.

Quote
ps had to resize the images to half size, the thing at the bottom of the fullscreen shot is the noscript bar
A lot of add-ons have drawing problems with the broken standard theme under OS/2 now.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 22, 2017, 07:25:41 pm
It all works fine here though it does have the same problem as Windows in not going to full screen from kiosk (F11) mode.
F11 full screen worked with your sm 2.7.2 build. Later it became broken in several ways.

Quote
Here's screenshots of the full screen video I get when clicking the full screen thingie at the bottom right of the video and the F11 results.
The picture doesn't show a full screen for video playback. I cannot recognise what's on the bottom there? Also the dimensions are strange for full screen.

My screen is 1680x1050 and I just halved the dimensions to shrink the screenshot. The thing at the bottom of the screen is the noscript thing that says that some scripts are forbidden.

Quote
Quote
Both restore fine to a window though restoring from F11 leaves the page somewhat up the page so I have to scroll down to get to where I was.
The behaviour is not consistent. Using a sized window and using F11 twice seems to work reliably. But starting with a maximised window and using F11 only restores to the defined size not to the maximised window. With Seamonkey 2.7.2 it's acceptable, only new started AVIO applications should causes redraw timing problems. With external NSPR in latest builds it's totally broken. No switch back for the window for video playback from forced foreground to the normal behavour seems to be the most annoying issue. So it's child windows are in the background and quite unusable.

OK, starting out with a maximized window, I can reproduce what your seeing, and yes it is very broken, needing the WPS reset and SM restarted to recover.
Interestingly, I reproduced it with Firefox, but after restarting the computer and reinstalling Firefox, Firefox seems to work properly.

Quote
Quote
I seem to have mis-remembered about Netscape supporting F11 but current SM F11 full screen looks almost the same as doing it with SM 1.19.
You can run netscape with the parameter -k to use the kiosk mode.

Quote
ps had to resize the images to half size, the thing at the bottom of the fullscreen shot is the noscript bar
A lot of add-ons have drawing problems with the broken standard theme under OS/2 now.

I haven't noticed that, though I haven't used many add-ons.
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on December 22, 2017, 07:43:24 pm

I attached the file seamonkey.log and the corresponding trp file.
saludos

Seems to be crashing when trying to load or check the Java plugin.
Two things you could try. Removing the Java plugin, or easier, just temporarily setting MOZ_PLUGIN_PATH to nothing, perhaps by remming it out in config.sys.
And trying just replacing blocklist.xml in your SM profile with the one from the Firefox profile.
Title: Re: Experimental build of SeaMonkey
Post by: roberto on December 23, 2017, 11:09:19 am
As you propose when removing from the Moz_plugin_path in config. sys the problem is resolved. And now when you close the Seamonkey it closes properly.
Saludos
Title: Re: Experimental build of SeaMonkey
Post by: Pete on March 20, 2018, 02:59:21 pm
Hi All

I am using the current SeaMonkey/2.42.9esr which has just started displaying a "nag message" on starting about this build of Seamonkey being old and I should check for updates.

How do I get rid of the "nag message"?


Regards

Pete
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on March 20, 2018, 03:14:01 pm
Haven't seen that. Try going to about:config (http://about:config), search for app.update, and toggle app.update.auto and/or app.update.enabled to false.
Let me know if it works and I can change the defaults.
Title: Re: Experimental build of SeaMonkey
Post by: Pete on March 20, 2018, 05:09:30 pm
Hi Dave

Looking at about.config I see these values:-

   app.update.auto;false
   app.update.enabled;false
   app.update.mode;0

I seem to recall those were the settings that turned off the "nag message" in previous Seamonkey builds but they do not seem to be working with this build...

Out of interest I clicked the Check for updates button which does nothing.


Regards

Pete


Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on March 20, 2018, 10:29:53 pm
That's strange. Are those settings bold? Bold would mean you changed them at some point.
Here they're set to true and I haven't seen the update message. You could try toggling them to true as perhaps upstream changed the defaults as SM updates are broken on all platforms last I heard.
Title: Re: Experimental build of SeaMonkey
Post by: Pete on March 20, 2018, 10:50:16 pm
Hi Dave

Yes, all those settings are shown in bold as I previously set them to *disable* this message - cannot remember which Seamonkey build, was probably a couple of years ago.

I toggled them to False, closed and restarted the browser: No message. It seems True is the new False...


Regards

Pete
Title: Re: Experimental build of SeaMonkey
Post by: Dave Yeo on March 21, 2018, 02:27:06 am
The options live under mozilla/ where Firefox and most of the code live and the SeaMonkey people couldn't just change the defaults so I guess they changed their code to do the opposite and default to no automatic updates.