Enhanced Mozilla applications updated to Gecko 1.8.1.18
Peter Weilbacher
<http://pmw-warpzilla.sf.net/>:
- SeaMonkey 1.1.13 (PmW)
- PmW-Fx 2.0.0.18
- PmW-Tb 2.0.0.18
They are all based on Gecko 1.8.1.18 on the date of 2008-11-13 and
built from the exact same sources. They correspond directly to the
respective official releases of SeaMonkey, Firefox, and hopefully
Thunderbird.
All applications need libc063.dll to run.
These releases pick up all the changes done by Mozilla since my Gecko
1.8.1.17 release, i.e. between 2008-08-27 and 2008-10-30. This includes
fixes for 11 security issues, 6 of them critical.
One minor problem was fixed in PmW-Tb:
- The en-US version shipped with wrong branding (as Mail/News instead of
PmW-Tb) in some earlier releases. This has now been fixed.
No OS/2 specific changes were otherwise done.
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Steve's Warpzilla Tips: http://www.os2bbs.com/os2news/Warpzilla.html
mike luther
Peter Weilbacher wrote:
> New versions of my enhanced Mozilla based apps are available now from
> <http://pmw-warpzilla.sf.net/>:
>
> - SeaMonkey 1.1.13 (PmW)
> - PmW-Fx 2.0.0.18
> - PmW-Tb 2.0.0.18
>
> They are all based on Gecko 1.8.1.18 on the date of 2008-11-13 and
> built from the exact same sources. They correspond directly to the
> respective official releases of SeaMonkey, Firefox, and hopefully
> Thunderbird.
> All applications need libc063.dll to run.
>
> These releases pick up all the changes done by Mozilla since my Gecko
> 1.8.1.17 release, i.e. between 2008-08-27 and 2008-10-30. This includes
> fixes for 11 security issues, 6 of them critical.
>
> One minor problem was fixed in PmW-Tb:
> - The en-US version shipped with wrong branding (as Mail/News instead of
> PmW-Tb) in some earlier releases. This has now been fixed.
> No OS/2 specific changes were otherwise done.
Your enhanced version as an installer works just fine so far on now five tried
boxes as an over install of your 1.1.12 enhanced version. I don't use it for
much of anything, but on the lowest level box so far as Warp 4 FP 17 at 256MB
of memory and 133Mhz of Intel processor; just perfect install and no problems
in basic turn on.
More realistic minimal box for actual use things of interest. On one box at
256MB of memory but at 600Mhz of AMD CPU I see no change in the generic
performance from 1.1.12 on that same box.
I actually have the Enhanced 1.1.12 version installed on one antique PIccollo
transportable CRT case I keep for treasured purposes. It has only a 133MHz CPU
and 192MB of memory in this SCSI drive classic even at Warp 4 FP 17 level. But
you can actually use your product on it even connected with 24,000 modem phone
line connections to the IP! Frankly, I doubt if there will be any problem on
it with 1.1.13 from what I've seen so far. I'll likely get to try the install
on it tomorrow.
Blessings to you and all those who keep working so hard for all of us here.
--
--> Sleep well; OS2's still awake! ;)
Mike Luther
Steve Wendt
> New versions of my enhanced Mozilla based apps are available now from
> <http://pmw-warpzilla.sf.net/>:
I meant to ask this for a while - what is it about the last change to
the SourceForge download pages that makes them eat up CPU time? If I
wait long enough, I get a popup about Javascript taking too long. It's
not as bad with Seamonkey 2.0a1, but it still takes more CPU than it should.
Blacklisted email address
> the SourceForge download pages that makes them eat up CPU time? If I
> wait long enough, I get a popup about Javascript taking too long. It's
> not as bad with Seamonkey 2.0a1, but it still takes more CPU than it
> should.
I've noticed that as well, also happens on http://www.theregister.co.uk/
when you move up n down the page. This happens in both official
Seamonkey and Enhanced Seamonkey.
Cheers
Ian Manners
PS, Thanks for the Enhanced builds Peter, very much appreciated,
especially all the hard work you and others do to keep Mozilla software
going for OS/2, as much as you can.
jim byrnes
> I've noticed that as well, also happens on http://www.theregister.co.uk/
> when you move up n down the page. This happens in both official
> Seamonkey and Enhanced Seamonkey.
>
> Cheers
> Ian Manners
>
I noticed it after they redesigned the front page. If you happen to be
scrolling in an area where the pictures on the right side are not
visible it is not too bad. For some reason Firefox seems to handle it
better then Seamonkey.
Regards, Jim
Peter Weilbacher
As usual my guess is the alpha-transparent PNGs that they use to
construct the background. Although that doesn't explain your JS popup,
which I have never seen. But you can see in the page info already that
there are several PNGs with suspicious names. I checked one
(grad_dark_50_dwn.png) and it indeed has an alpha channel with 1% to 6%
opacity.
I never noticed the problems before, sorry for causing especially the
target audience such problems!
Steve Wendt
>> I meant to ask this for a while - what is it about the last change to
>> the SourceForge download pages that makes them eat up CPU time? If I
>> wait long enough, I get a popup about Javascript taking too long. It's
>> not as bad with Seamonkey 2.0a1, but it still takes more CPU than it
>> should.
>
> As usual my guess is the alpha-transparent PNGs that they use to
That was my first guess, but the HTML source didn't show anything
obviously being tiled, and setting the CSS styles to None didn't help.
If I disable Javascript, the download page doesn't work, but it doesn't
suck up any CPU time, either.
> I never noticed the problems before, sorry for causing especially the
> target audience such problems!
I'm certainly not blaming you! ;-)
I know you don't have any control over SourceForge. I was just hoping
someone might have a suggestion... I guess if I get too annoyed, I can
start hacking up their Javascript to figure out what is going on - that
got FlashBlock fixed, after all. ;-)
Steve Wendt
> That was my first guess, but the HTML source didn't show anything
> obviously being tiled, and setting the CSS styles to None didn't help.
> If I disable Javascript, the download page doesn't work, but it doesn't
> suck up any CPU time, either.
OK, now I'm confused - I tried it again, and the download page works
fine with Javascript disabled. There are some CPU spikes when I scroll
the page, which certainly could be the PNG issue, as those don't happen
with the style set to None.
The Javascript issue could be related to an extension - I'm suspicious
of MediaPlayerConnectivity.
Wolfi
> On 15.11.08 06:07, Steve Wendt wrote:
>> I meant to ask this for a while - what is it about the last change to
>> the SourceForge download pages that makes them eat up CPU time? If I
>> wait long enough, I get a popup about Javascript taking too long. It's
>> not as bad with Seamonkey 2.0a1, but it still takes more CPU than it
>> should.
>
> As usual my guess is the alpha-transparent PNGs that they use to
> construct the background. Although that doesn't explain your JS popup,
> which I have never seen. But you can see in the page info already that
> there are several PNGs with suspicious names. I checked one
> (grad_dark_50_dwn.png) and it indeed has an alpha channel with 1% to 6%
> opacity.
I just tried to d/l your latest builds, using Mozilla/5.0 (OS/2; U; Warp
4.5; en-US; rv:1.9.1b1pre) Gecko/20081008000000 SeaMonkey/2.0a1/.
As an addendum to what Steve W. just reported about this issue:
With the SF page loaded, I have a CPU load of 99.9%, which doesn't
change when I disable "Use Style" via the View menu, nor when I disable
all PNG that AdBlockPlus reveals, using these 3 filters:
fsdn.com/sf/images//phoneix/*.png
fsdn.com/sf/images/phoneix/*.png
sourceforge.net/images/facebox/*.png
The CPU load only goes back to normal, when I allow NoScript to block
all scripts from sourceforge.net.
This is still true, when I then re-enable "Use Style" and remove those
above 3 ABP filters again.
My conclusion as well: whatever is going on @SF right now, is caused by
some weird CPU-hogging JS stuff.
The known PNG transparency problem doesn't seem to be the culprit this time.
rafe
superb -- renders handsomely & is extremely stable, in marked contrast
to the general release 1.1.12, which for some reason not only tended
to crash on an almost hourly basis, but was also very resource
intensive.
many many thanks.
Barbara
wrote:
I know I'm slow, but this morning when I tried to download,
sourceforge wouldn't work at all. Firefox reported a "script in
process" do you want to "stop script" or "continue. Neither worked
and the information box kept popping up. Couldn't even shut down the
browser in a normal fastion, but had to "kill" it. This is plain
vanilla Firefox 2.0.0.14 with Java 1.4 (latest), and no filters,
extensions, plugins.
Had to boot XP and use that Seamonkey version to download.
--
Barbara
David Graser
Barbara, why don't you install Seamonkey 1.13 in addition to Firefox. I
have had no problems with Seamonkey and prefer it to the Windows version.
David
Barbara
wrote:
>
> Barbara, why don't you install Seamonkey 1.13 in addition to Firefox. I
> have had no problems with Seamonkey and prefer it to the Windows version.
I downloaded 1.13 and usually use Seamonkey. Also got new Firefox and
Thunderbird.
I had already tried Seamonkey for the download, then tried Firefox.
They both got stuck and I should have mentioned that. I've had super
slow downloads from Sourceforge before, but this morning it would not
cooperate at all.
It doesn't cancel the frustration, but I'm relieved to see others
having similar problems. Something is NOT right!
--
Barbara
Rich Walsh
> On Sun, 16 Nov 2008 01:59:47 UTC, Wolfi wrote:
> > My conclusion as well: whatever is going on @SF right now, is
> > caused by some weird CPU-hogging JS stuff. The known PNG
> > transparency problem doesn't seem to be the culprit this time.
>
> I know I'm slow, but this morning when I tried to download,
> sourceforge wouldn't work at all. Firefox reported a "script in
> process" do you want to "stop script" or "continue. Neither worked
> and the information box kept popping up. Couldn't even shut down the
> browser in a normal fastion, but had to "kill" it. This is plain
> vanilla Firefox 2.0.0.14 with Java 1.4 (latest), and no filters,
> extensions, plugins.
I tried this page with FF 3.0 & encountered the same issues as
everyone else. I then used Firebug to delete each block of
JavaScript (and there's a lot!) in the hope of finding the
culprit. I never succeeded.
However, I did find that if JS is disabled when you load the page,
you can then reenable it and download stuff without suffering 100%
CPU usage. This suggests that the cause is a script that's created
on-the-fly - and all of those involve Google's advertising. If you
enter the page with JS disabled, you'll notice that none of the ads
on the right side ever show up, even after you reenable it.
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
Steve Wendt
> This suggests that the cause is a script that's created
> on-the-fly - and all of those involve Google's advertising. If you
> enter the page with JS disabled, you'll notice that none of the ads
> on the right side ever show up, even after you reenable it.
Interesting... for what it's worth, it has ridiculous amounts of CPU
usage on Win32 also, so at least it's not an OS/2-specific problem
(although the effect may be more obvious).
Dave Yeo
> I tried this page with FF 3.0& encountered the same issues as
> everyone else. I then used Firebug to delete each block of
> JavaScript (and there's a lot!) in the hope of finding the
> culprit. I never succeeded.
>
> However, I did find that if JS is disabled when you load the page,
> you can then reenable it and download stuff without suffering 100%
> CPU usage. This suggests that the cause is a script that's created
> on-the-fly - and all of those involve Google's advertising. If you
> enter the page with JS disabled, you'll notice that none of the ads
> on the right side ever show up, even after you reenable it.
>
I have privoxy installed. Sourceforge works fine, close to zero cpu
usage. All scripts are enabled with noscript so it must be one of those
advertisements that I don't see.
Dave
Barbara
<spamyo...@127.0.0.1> wrote:
> On Thu, 20 Nov 2008 16:33:56 UTC, "Barbara" wrote:
> > On Sun, 16 Nov 2008 01:59:47 UTC, Wolfi wrote:
>
> > > My conclusion as well: whatever is going on @SF right now, is
> > > caused by some weird CPU-hogging JS stuff. The known PNG
> > > transparency problem doesn't seem to be the culprit this time.
> >
> > I know I'm slow, but this morning when I tried to download,
> > sourceforge wouldn't work at all. Firefox reported a "script in
> > process" do you want to "stop script" or "continue. Neither worked
> > and the information box kept popping up. Couldn't even shut down the
> > browser in a normal fastion, but had to "kill" it. This is plain
> > vanilla Firefox 2.0.0.14 with Java 1.4 (latest), and no filters,
> > extensions, plugins.
>
> I tried this page with FF 3.0 & encountered the same issues as
> everyone else. I then used Firebug to delete each block of
> JavaScript (and there's a lot!) in the hope of finding the
> culprit. I never succeeded.
>
> However, I did find that if JS is disabled when you load the page,
> you can then reenable it and download stuff without suffering 100%
> CPU usage. This suggests that the cause is a script that's created
> on-the-fly - and all of those involve Google's advertising. If you
> enter the page with JS disabled, you'll notice that none of the ads
> on the right side ever show up, even after you reenable it.
Fantastic! That did work, and I didn't even turn javascript back on.
This was with Seamonkey 1.1.8. It was very slow scrolling the
application page, like it knew something was missing.
Only issue is one that may not have anything to do with Sourceforge
advertising. Slower, and slower and slower on the downloads. FF took
seconds, TB took five minutes and Seamonkey took almost ten minutes.
I've seen that before on multiple downloads. Starts at 300plus
Kb/sec, ends up at 28.8 Kb/sec. Maybe there were more than three of
us downloading?
--
Barbara
Steve Wendt
> Only issue is one that may not have anything to do with Sourceforge
> advertising. Slower, and slower and slower on the downloads. FF took
> seconds, TB took five minutes and Seamonkey took almost ten minutes.
> I've seen that before on multiple downloads. Starts at 300plus
> Kb/sec, ends up at 28.8 Kb/sec. Maybe there were more than three of
> us downloading?
SourceForge picks a download server (semi?)randomly. You could end up
getting a slower one after the first time. Alternatively, you could get
the same one, which decides to throttle your bandwidth if it sees
multiple connections from you.
Barbara
wrote:
Maybe. Those are pretty hefty downloads, and I suppose not everyone
tries to get all three at once.
--
Barbara
Peter Weilbacher
> On 11/20/2008 3:41 PM, Rich Walsh wrote:
>
> > This suggests that the cause is a script that's created
> > on-the-fly - and all of those involve Google's advertising. If you
> > enter the page with JS disabled, you'll notice that none of the ads
> > on the right side ever show up, even after you reenable it.
That probably also explains why on my installations I don't see it. I
use an adapted hosts file to block ad servers.
> Interesting... for what it's worth, it has ridiculous amounts of CPU
> usage on Win32 also, so at least it's not an OS/2-specific problem
> (although the effect may be more obvious).
And indeed it got reported by someone else, too, in their bug tracker:
Package view page causes 100% CPU usage on FF2 and others
https://sourceforge.net/tracker/index.php?func=detail&aid=2322430&group_
id=1&atid=200001
But unlike other such systems they discourage adding comments... So
let's wait and watch if that report really gets them to change something
for the better.
Steve Wendt
> And indeed it got reported by someone else, too, in their bug tracker:
> Package view page causes 100% CPU usage on FF2 and others
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2322430&group_
> id=1&atid=200001
Great! I'm surprised it didn't get reported until today; I guess like
me, no one bothered to complain sooner.