[New] Firefox and Seamonkey Betas

New betas of Firefox and Seamonkey are now available.  They feature
the latest Mozilla code plus small refinements to the OS/2 features
seen in previous betas.

* Firefox v4.0b12pre:
    ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
  or
    http://e-vertise.com/warpzilla/firefox-20110210.zip
 
* Seamonkey v2.1b3pre:
    ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
  or
    http://e-vertise.com/warpzilla/seamonkey-20110210.zip

New
---
Printing at 600 dpi is now supported, provided the page requires no
more than 144mb to compose (an A4- or Letter-sized page uses 132mb
at 600dpi but only 34mb at 300dpi).

If you use the apps' built-in Postscript support and print directly
to a PS printer, an experimental option may enable you to use printer
features such as duplexing. See 'PRINTING.TXT' in the exe's directory
for details.

SNAP users should no longer experience video corruption caused by the
mouse pointer when DIVE is enabled.  The apps are now able to detect
whether SNAP is using a hardware- or software-generated mouse pointer.

These releases include a beta version of Exceptq v7.1 to create an
exception report whenever a crash occurs within the app.  They also
include debugging files that have a '.xqs' extension.  Please do not
delete them.  If you don't want these reports to be created, add
"SET NSPR_NO_EXCEPTQ=Y" to your config.sys.


Previous Enhancements
---------------------
Video:  Dramatic reductions in CPU usage will be seen when viewing OGG
videos, and to a lesser extent, WebM videos.  Overall video performance
should be noticeably improved for SNAP and GenGradd users running their
displays in full-color mode, thanks to the implementation of DIVE.

Printing Support:  All native printer drivers will work if their output
resolution is set to 600 DPI or less.  Mozilla's built-in Postscript
support is also available for use, as is its PDF support.  Please read
PRINTING.txt in the exe's directory for details.

Memory Management:  With a few trivial exceptions, the Mozilla apps no
longer use any shared memory beyond what is needed to load their dlls.
Problems that have been attributed to low or no shared memory should
not occur.

Font Selection:  The apps should do a better job of selecting DBCS fonts
and fonts with less common font weights such as "Thin" or "Heavy".

Copy Link Location: A bug that caused characters to be deleted from URLs
when using the 'Copy Link Location' menu item has been fixed.


Bugs
----
Both apps will occasionally "smear" the video when scrolling.  In most
cases, the easiest workaround is to resize the window slightly to force
its redisplay.


Notes
-----
DIVE lets an app bypass PM's graphics subsystem and write directly to
your video card's memory.  This improves display speed but can cause
problems on some systems.  Use the following to disable DIVE:

- uncheck "Use hardware acceleration when possible".
  In Firefox, it's on the Options dialog's 'Advanced->General' tab.
  In Seamonkey, this is in Preferences under 'Appearance->Content'.
- start the app in "safe mode" (use "/safe-mode" on the command line)
- add "SET MOZ_ACCELERATED=0" to config.sys.


Support
-------
Community support for these betas and all Mozilla apps is available
through the newsgroups 'mozilla.dev.ports.os2' or 'comp.os.os2.apps'.
Messages posted to other forums may not be seen by the developers.


Rich Walsh <richATe-vertiseDOTcom>

-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/11/2011 6:23:01 AM
mozilla.dev.ports.os2 2335 articles. 0 followers. Post Follow

134 Replies
886 Views

Similar Articles

[PageSpeed] 18

Rich Walsh wrote:

> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.

The starting in offline state problem is gone, wonderful.  :-)
0
Steve
2/11/2011 8:03:47 AM
On Fri, 11 Feb 2011 08:03:47 UTC, Steve Wendt <spamsux@forgetit.org> 
wrote:

> Rich Walsh wrote:
> 
> > New betas of Firefox and Seamonkey are now available.  They feature
> > the latest Mozilla code plus small refinements to the OS/2 features
> > seen in previous betas.
> 
> The starting in offline state problem is gone, wonderful.  :-)

And feels really fast on this slow machine, thanks.

-- 
Hessu
Feel free to correct my English :-)
0
Heikki
2/11/2011 9:12:06 AM
On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

Thanks Rich

> 
> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.

<snip>

> SNAP users should no longer experience video corruption caused by the
> mouse pointer when DIVE is enabled.  The apps are now able to detect
> whether SNAP is using a hardware- or software-generated mouse pointer.

I still get a blank square where the mouse was on occasion. Latest 
SNAP.

Just before I installed this beta the previous one, December's, got so
slow it was unusable. I have nearly everything I can think of that 
uses SQL turned off and it still pegs the CPU at 100% for tens of 
seconds at a time. This is on a T23 BTW.

-- 
Regards
Dave Saville
0
Dave
2/11/2011 10:38:43 AM
Rich Walsh wrote:
>
> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.
>
> * Firefox v4.0b12pre:
>      ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>    or
>      http://e-vertise.com/warpzilla/firefox-20110210.zip
>
> * Seamonkey v2.1b3pre:
>      ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>    or
>      http://e-vertise.com/warpzilla/seamonkey-20110210.zip


Hallo Rich,

thanks for this new version. I second that the "always start in offline mode"
problem is gone.

What I still cannot get to work is printing. I do have a PS printer and therefore
the PS driver installed. I observe this:
1.) If I try to print an email and chose "Print" I don't even get to the point to have a choice to save
     it as PDF. I always get a "printer not available" error
2.) If I try to print an email and choose "Print Preview" instead, it's a a bit different.
     The print job will spool to the spooler directory (say \var\SPOOL\BrotherH) and it will disappear
     from there but the job is never printed.
3.) If I print a webpage I have the same effect as in 2.).

I guess 2.) and 3.) coincede as in both case the printer selection dialog pops up whereas in 1.) it does not.

Note: I have added via "about:config"
print.os2.postscript.use_builtin "true"
print.os2.postscript.use_ibmnull "false"


Lars

0
Lars
2/11/2011 11:01:34 AM
On Fri, 11 Feb 2011 11:01:34 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> The print job will spool to the spooler directory (say \var\SPOOL\BrotherH)
> and it will disappear from there but the job is never printed.

I have at least 8 different drivers installed, and if I associate any of
them with a port, the exact same thing happens.  The only difference is
that I don't actually have any of those printers :-)  What I'm getting
at is that I don't get to see little lights on the printer blink before
it doesn't do anything.  Do you see any activity at the printer?

> Note: I have added via "about:config"
> print.os2.postscript.use_builtin "true"
> print.os2.postscript.use_ibmnull "false"

My guess is that 25% of printers don't like Cairo's postscript and
just blink a bunch but never print.  Change 'use_builtin' to "false"
and see if it works using the native PS driver.


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/11/2011 1:50:55 PM
On Fri, 11 Feb 2011 10:38:43 UTC, "Dave Saville" wrote:
> On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh" wrote:
> 
> > SNAP users should no longer experience video corruption caused by the
> > mouse pointer when DIVE is enabled.  The apps are now able to detect
> > whether SNAP is using a hardware- or software-generated mouse pointer.
> 
> I still get a blank square where the mouse was on occasion. Latest 
> SNAP.

The version of SNAP that comes with eCS (the final one?) was not necessarily
the best.  With my old video card (an older ATI), the pointer would sometimes
turn into a black square when crossing the resizing bar in the middle of
ProNews' main window.  That never happened with my previous version of SNAP.
If you disable DIVE, does the problem go away?  (At the bottom of the
announcement are details on how to do this.)

> Just before I installed this beta the previous one, December's, got so
> slow it was unusable. I have nearly everything I can think of that 
> uses SQL turned off and it still pegs the CPU at 100% for tens of 
> seconds at a time. This is on a T23 BTW.

These versions have several OS/2-specific changes in sqlite.  Honestly,
I'm not optimistic they will have improved things - but we can hope...


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/11/2011 2:10:37 PM
On Fri, 11 Feb 2011 13:50:55 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Fri, 11 Feb 2011 11:01:34 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
> 
> > The print job will spool to the spooler directory (say \var\SPOOL\BrotherH)
> > and it will disappear from there but the job is never printed.
> 
> I have at least 8 different drivers installed, and if I associate any of
> them with a port, the exact same thing happens.  The only difference is
> that I don't actually have any of those printers :-)  What I'm getting
> at is that I don't get to see little lights on the printer blink before
> it doesn't do anything.  Do you see any activity at the printer?
> 
> > Note: I have added via "about:config"
> > print.os2.postscript.use_builtin "true"
> > print.os2.postscript.use_ibmnull "false"
> 
> My guess is that 25% of printers don't like Cairo's postscript and
> just blink a bunch but never print.  Change 'use_builtin' to "false"
> and see if it works using the native PS driver.
> 
> 
Hi Rich,

First thankz for you're great work..
I have a Hp 1320N

I can only print on 300dpi if i try 600 notting happens...

-- 

0
TeLLie
2/11/2011 4:20:02 PM
Hi Rich

Rich Walsh wrote:
>
> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.
>
> * Firefox v4.0b12pre:
>      ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>    or
>      http://e-vertise.com/warpzilla/firefox-20110210.zip
>
> * Seamonkey v2.1b3pre:
>      ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>    or
>      http://e-vertise.com/warpzilla/seamonkey-20110210.zip
>
>


I  deleted the contents of my seamonkey directory then unzipped this 
build to a temp location and then copied files and directories to the 
Seamonkey directory - this way I do not have to change existing 
Seamonkey program objects when changing Seamonkey builds.

I then started Seamonkey and it performed the "Addons check" producing a 
list of incompatible addons. These included:-

Seamonkey Debug and QA UI 1.0pre
Chatzilla 0.9.86
JavaScript Debugger 0.9.88.1

All of the above are Seamonkey supplied Addons, part of the just 
unzipped build.

So, something wrong there.

The Addons check offers to check for later versions of the incompatible 
Addons but failed to find any.

I clicked the Finish button and Seamonkey started in "offline mode". As 
I have seen reports that it now starts in "online mode" this surprised me.

I changed to "online mode" and clicked "Try again" which loaded the 
webpage fine.

I then closed Seamonkey typed a couple of lines in this report and then 
restarted Seamonkey. Ok, it started in "online mode" so that looks like 
1 minor irritant resolved.


I guess I am going to have to hunt through the ng and Mozilla bugs pages 
to find the "cure" for the supplied Addons being "incompatible" - I did 
have this with the previous build but cannot remember offhand how to 
resolve this.

I opened the Addons Manager to remind myself of the other addons that 
need "fiddling" or removing.

The Addons Manager page is not scrollable vertically or horizontally due 
to lack of scroll bars. The same applies to other pages selectable from 
the menu to the left of this page. Looks like another problem found - 
theme in use is Modern.


Regards

Pete

0
Peter
2/11/2011 4:29:56 PM
On 02/11/11 08:29 am, Peter Brown wrote:
> Hi Rich
>
> Rich Walsh wrote:
>>
>> New betas of Firefox and Seamonkey are now available. They feature
>> the latest Mozilla code plus small refinements to the OS/2 features
>> seen in previous betas.
>>
>> * Firefox v4.0b12pre:
>> ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>> or
>> http://e-vertise.com/warpzilla/firefox-20110210.zip
>>
>> * Seamonkey v2.1b3pre:
>> ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>> or
>> http://e-vertise.com/warpzilla/seamonkey-20110210.zip
>>
>>
>
>
> I deleted the contents of my seamonkey directory then unzipped this
> build to a temp location and then copied files and directories to the
> Seamonkey directory - this way I do not have to change existing
> Seamonkey program objects when changing Seamonkey builds.
>
> I then started Seamonkey and it performed the "Addons check" producing a
> list of incompatible addons. These included:-
>
> Seamonkey Debug and QA UI 1.0pre
> Chatzilla 0.9.86
> JavaScript Debugger 0.9.88.1
>
> All of the above are Seamonkey supplied Addons, part of the just
> unzipped build.
>
> So, something wrong there.
>
> The Addons check offers to check for later versions of the incompatible
> Addons but failed to find any.
>
> I clicked the Finish button and Seamonkey started in "offline mode". As
> I have seen reports that it now starts in "online mode" this surprised me.
>
> I changed to "online mode" and clicked "Try again" which loaded the
> webpage fine.
>
> I then closed Seamonkey typed a couple of lines in this report and then
> restarted Seamonkey. Ok, it started in "online mode" so that looks like
> 1 minor irritant resolved.
>
>
> I guess I am going to have to hunt through the ng and Mozilla bugs pages
> to find the "cure" for the supplied Addons being "incompatible" - I did
> have this with the previous build but cannot remember offhand how to
> resolve this.
>
> I opened the Addons Manager to remind myself of the other addons that
> need "fiddling" or removing.
>
> The Addons Manager page is not scrollable vertically or horizontally due
> to lack of scroll bars. The same applies to other pages selectable from
> the menu to the left of this page. Looks like another problem found -
> theme in use is Modern.
>

IIRC the trick with the addons is to disable them, restart, then 
re-enable them.
You might want to change to the standard theme for a working addons 
manager page, it is all works in progress so not sure if OS/2 bug or 
general bug.
Dave
0
Dave
2/11/2011 4:37:22 PM
Hi Dave

Dave Yeo wrote:
> On 02/11/11 08:29 am, Peter Brown wrote:
>> Hi Rich
>>
>> Rich Walsh wrote:
>>>
>>> New betas of Firefox and Seamonkey are now available. They feature
>>> the latest Mozilla code plus small refinements to the OS/2 features
>>> seen in previous betas.
>>>
>>> * Firefox v4.0b12pre:
>>> ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>>> or
>>> http://e-vertise.com/warpzilla/firefox-20110210.zip
>>>
>>> * Seamonkey v2.1b3pre:
>>> ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>>> or
>>> http://e-vertise.com/warpzilla/seamonkey-20110210.zip
>>>
>>>
>>
>>
>> I deleted the contents of my seamonkey directory then unzipped this
>> build to a temp location and then copied files and directories to the
>> Seamonkey directory - this way I do not have to change existing
>> Seamonkey program objects when changing Seamonkey builds.
>>
>> I then started Seamonkey and it performed the "Addons check" producing a
>> list of incompatible addons. These included:-
>>
>> Seamonkey Debug and QA UI 1.0pre
>> Chatzilla 0.9.86
>> JavaScript Debugger 0.9.88.1
>>
>> All of the above are Seamonkey supplied Addons, part of the just
>> unzipped build.
>>
>> So, something wrong there.
>>
>> The Addons check offers to check for later versions of the incompatible
>> Addons but failed to find any.
>>
>> I clicked the Finish button and Seamonkey started in "offline mode". As
>> I have seen reports that it now starts in "online mode" this surprised
>> me.
>>
>> I changed to "online mode" and clicked "Try again" which loaded the
>> webpage fine.
>>
>> I then closed Seamonkey typed a couple of lines in this report and then
>> restarted Seamonkey. Ok, it started in "online mode" so that looks like
>> 1 minor irritant resolved.
>>
>>
>> I guess I am going to have to hunt through the ng and Mozilla bugs pages
>> to find the "cure" for the supplied Addons being "incompatible" - I did
>> have this with the previous build but cannot remember offhand how to
>> resolve this.
>>
>> I opened the Addons Manager to remind myself of the other addons that
>> need "fiddling" or removing.
>>
>> The Addons Manager page is not scrollable vertically or horizontally due
>> to lack of scroll bars. The same applies to other pages selectable from
>> the menu to the left of this page. Looks like another problem found -
>> theme in use is Modern.
>>
>
> IIRC the trick with the addons is to disable them, restart, then
> re-enable them.
> You might want to change to the standard theme for a working addons
> manager page, it is all works in progress so not sure if OS/2 bug or
> general bug.
> Dave



Changed theme to Default and restarted Seamonkey.

No problems with the Addons Manager pages now - but why were there 
problems using the Modern theme supplied with this build?

The trick with Addons needing to be Disabled seems to ring a bell so I 
thought I'd give it a try for those addons supplied with the build. 
However, those addons already show as Disabled with no option to Enable 
them.

Meanwhile I found my ng post about this problem encountered previously 
and followed up with re-reading my bug report 
https://bugzilla.mozilla.org/show_bug.cgi?id=609524

Sadly the "cure" offered in that bug report no longer applies as there 
is no option to uninstall - the Remove button is missing - the 3 
seamonkey supplied extensions in order to start the "cure".


Regards

Pete
0
Peter
2/11/2011 4:59:42 PM
On Fri, 11 Feb 2011 14:10:37 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Fri, 11 Feb 2011 10:38:43 UTC, "Dave Saville" wrote:
> > On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh" wrote:
> > 
> > > SNAP users should no longer experience video corruption caused by the
> > > mouse pointer when DIVE is enabled.  The apps are now able to detect
> > > whether SNAP is using a hardware- or software-generated mouse pointer.
> > 
> > I still get a blank square where the mouse was on occasion. Latest 
> > SNAP.
> 
> The version of SNAP that comes with eCS (the final one?) was not necessarily
> the best.  With my old video card (an older ATI), the pointer would sometimes
> turn into a black square when crossing the resizing bar in the middle of
> ProNews' main window.  That never happened with my previous version of SNAP.
> If you disable DIVE, does the problem go away?  (At the bottom of the
> announcement are details on how to do this.)
> 

Is that uncheck the option *and* set the environmental, or either?


> > Just before I installed this beta the previous one, December's, got so
> > slow it was unusable. I have nearly everything I can think of that 
> > uses SQL turned off and it still pegs the CPU at 100% for tens of 
> > seconds at a time. This is on a T23 BTW.
> 
> These versions have several OS/2-specific changes in sqlite.  Honestly,
> I'm not optimistic they will have improved things - but we can hope...
> 
> 


-- 
Regards
Dave Saville
0
Dave
2/11/2011 5:43:43 PM
Peter Brown wrote:
> Hi Dave
>
[...]
>
>
> Changed theme to Default and restarted Seamonkey.
>
> No problems with the Addons Manager pages now - but why were there
> problems using the Modern theme supplied with this build?

There seems to have been problems with Addons Manager and the modern 
theme for a while. As I said I'm not sure if this is OS/2 specific but 
assuming it is then it is a matter of no one having looked at it. Walter 
knows more about the UI and has recently posted a couple of fixes for 
the default theme but maybe hasn't had much time to look at modern.
SeaMonkey itself is not an official Mozilla project and is also 
suffering from a shortage of manpower which results in minor bugs taking 
a while to fix.

>
> The trick with Addons needing to be Disabled seems to ring a bell so I
> thought I'd give it a try for those addons supplied with the build.
> However, those addons already show as Disabled with no option to Enable
> them.
>
> Meanwhile I found my ng post about this problem encountered previously
> and followed up with re-reading my bug report
> https://bugzilla.mozilla.org/show_bug.cgi?id=609524
>
> Sadly the "cure" offered in that bug report no longer applies as there
> is no option to uninstall - the Remove button is missing - the 3
> seamonkey supplied extensions in order to start the "cure".
>

Interesting, the extensions have been working here for quite a while and 
I have buttons to disable but not remove. Can't really see anything in 
about:config either.
After backing up your profile and shutting down SeaMonkey you might want 
to try deleting addons.* and extensions.*. I haven't tested this so not 
sure if they will be recreated so as I said backup your profile first.
Dave
0
Dave
2/11/2011 5:45:06 PM
On Fri, 11 Feb 2011 06:23:01 UTC "Rich Walsh" <spamyourself@127.0.0.1>
wrote:

Thanks, firefox looks good.

Trying some featured personas on the add-ons->appearance page I got a 
trap. I can supply *.trp and processdump, if wanted.

CU/2
-- 
Frank Beythien   fBeythien AT gmx.de
0
Frank
2/11/2011 5:59:59 PM
Hi Dave

Dave Yeo wrote:
> Peter Brown wrote:
>> Hi Dave
>>
> [...]
>>
>>
>> Changed theme to Default and restarted Seamonkey.
>>
>> No problems with the Addons Manager pages now - but why were there
>> problems using the Modern theme supplied with this build?
>
> There seems to have been problems with Addons Manager and the modern
> theme for a while. As I said I'm not sure if this is OS/2 specific but
> assuming it is then it is a matter of no one having looked at it. Walter
> knows more about the UI and has recently posted a couple of fixes for
> the default theme but maybe hasn't had much time to look at modern.
> SeaMonkey itself is not an official Mozilla project and is also
> suffering from a shortage of manpower which results in minor bugs taking
> a while to fix.
>
>>
>> The trick with Addons needing to be Disabled seems to ring a bell so I
>> thought I'd give it a try for those addons supplied with the build.
>> However, those addons already show as Disabled with no option to Enable
>> them.
>>
>> Meanwhile I found my ng post about this problem encountered previously
>> and followed up with re-reading my bug report
>> https://bugzilla.mozilla.org/show_bug.cgi?id=609524
>>
>> Sadly the "cure" offered in that bug report no longer applies as there
>> is no option to uninstall - the Remove button is missing - the 3
>> seamonkey supplied extensions in order to start the "cure".
>>
>
> Interesting, the extensions have been working here for quite a while and
> I have buttons to disable but not remove. Can't really see anything in
> about:config either.
> After backing up your profile and shutting down SeaMonkey you might want
> to try deleting addons.* and extensions.*. I haven't tested this so not
> sure if they will be recreated so as I said backup your profile first.
> Dave


That would be Profiles as the problem occurs with every existing Profile.

I'll give the "backup Profile and delete files addons.* and 
extensions.*" a go and report back.

Here is what I have been up to for the past hour or so:-

I tried running Seamonkey using a Profile, Tester, that has only been 
used once before and has no addons - apart from any data from those 
supplied with the previous Seamonkey build. In fact, this Profile was 
created to test for these "incompatibilities" with the last Seamonkey 
build and did not have these "incompatible" problems then.

On starting the Addons Checker did it's thing and reported the same 3 
Seamonkey supplied addons as "incompatible".

This suggests to me that the Addons Checker is finding something in 
existing Profiles that causes it to declare the addons as incompatible.

To test this I exited Seamonkey, restarted using ProfileManager to 
create a new Profile called Test, and then selected Test as the Profile 
to use. No problems, no "incompatible" addons listed in the Addons 
Manager - probably because the Addons Checker did *not* run.

That seems to confirm the problem occurs with the Addons Checker finding 
something relating to the addons supplied in the previous Seamonkey 
build that it does not like in Profiles that were working fine with the 
previous Seamonkey.


On a slightly different note: I have several Profiles in my 
Desktop\Internet\Seamonkey folder. When the folder is open on the 
Desktop all Profiles and the Seamonkey program object have the icons 
displayed correctly but when I view this folder by clicking the eCS 
"button" on the eComCenter and working through Internet -> Seamonkey the 
list shows mucked up icons for all Profiles with the exception of 
losepete (this Profile) and the Seamonkey object whose icons display 
correctly. Any ideas on the cause of this?


Regards

Pete


0
Peter
2/11/2011 6:13:32 PM
On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote: 

> These releases include a beta version of Exceptq v7.1 to create an
> exception report whenever a crash occurs within the app. 

Just got one. It is not reproducable, since browser restart to same
pages, and didn't crash again.

Interested in the TRP file ?

-- 
  Allan.

It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
0
Allan
2/11/2011 6:40:07 PM
Hi Dave

Peter Brown wrote:
> Hi Dave
>
> Dave Yeo wrote:
>> Peter Brown wrote:
>>> Hi Dave
>>>
>> [...]
>>>
>>>
>>> Changed theme to Default and restarted Seamonkey.
>>>
>>> No problems with the Addons Manager pages now - but why were there
>>> problems using the Modern theme supplied with this build?
>>
>> There seems to have been problems with Addons Manager and the modern
>> theme for a while. As I said I'm not sure if this is OS/2 specific but
>> assuming it is then it is a matter of no one having looked at it. Walter
>> knows more about the UI and has recently posted a couple of fixes for
>> the default theme but maybe hasn't had much time to look at modern.
>> SeaMonkey itself is not an official Mozilla project and is also
>> suffering from a shortage of manpower which results in minor bugs taking
>> a while to fix.
>>
>>>
>>> The trick with Addons needing to be Disabled seems to ring a bell so I
>>> thought I'd give it a try for those addons supplied with the build.
>>> However, those addons already show as Disabled with no option to Enable
>>> them.
>>>
>>> Meanwhile I found my ng post about this problem encountered previously
>>> and followed up with re-reading my bug report
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=609524
>>>
>>> Sadly the "cure" offered in that bug report no longer applies as there
>>> is no option to uninstall - the Remove button is missing - the 3
>>> seamonkey supplied extensions in order to start the "cure".
>>>
>>
>> Interesting, the extensions have been working here for quite a while and
>> I have buttons to disable but not remove. Can't really see anything in
>> about:config either.
>> After backing up your profile and shutting down SeaMonkey you might want
>> to try deleting addons.* and extensions.*. I haven't tested this so not
>> sure if they will be recreated so as I said backup your profile first.
>> Dave
>
>
> That would be Profiles as the problem occurs with every existing Profile.
>
> I'll give the "backup Profile and delete files addons.* and
> extensions.*" a go and report back.
>


With Seamonkey not running I copied all addons.* and extensions.* files 
to new filenames.

I then started Seamonkey with this Profile (losepete).

Opening the Addons Manager I see that nearly all of my Addons that were 
previously "incompatible" - both Seamonkey supplied and those added 
myself - are now Compatible. There is 1 Seamonkey supplied addon that is 
still "incompatible" though: DOM Inspector 2.0.8 is incompatible with 
Seamonkey 2.1b3pre and shows (disabled).

It does now have a Remove button though so gave removing it a try. After 
clicking Remove there was no message about needing to Restart Seamonkey.

I restarted Seamonkey and checked the Addons Manager again. This told me 
"DOM Inspector will be enabled after you restart Seamonkey" and there is 
a Restart Now button which I clicked. Hmmm... that did a lot of good as 
the reloaded page says exactly the same thing. However I see there is a 
Disable button despite the fact that the addon is shown as Disabled - 
not sure if this button showed on the first attempt...

I clicked Disable and the button changed to Enable - no option to 
Restart Now.

I clicked Enable and the Restart Now option reappeared so I clicked that.

After restart the DOM Inspector shows as working; ie there is no 
"incompatible" message, it is not shown as Disabled and a Disable button 
exists.


What a lot of performance to get the standard Seamonkey supplied addons 
"compatible" and Enabled... especially if you have several Profiles all 
with the same problem.

I guess something in the Profiles addons.* and/or extensions.* files 
causes the Addons Checker to declare *compatible* addons as "incompatible".


Now to see if I can get my 1 remaining not-Seamonkey-supplied 
incompatible addon, British English Dictionary 1.19.1, to be compatible 
and enabled.

That was easy - simply Remove, restart Seamonkey, drag'n'drop the xpi 
file onto Seamonkey, install, Restart, check Addons Manager - and, 
voila! Dictionary installed and Enabled.


Should I re-visit my bugzilla bug and file a report on the 
"incompatible" Seamonkey supplied addons and what steps I took to get 
them "compatible" and Enabled?


Regards

Pete


0
Peter
2/11/2011 7:15:09 PM
Peter Brown wrote:

> I then started Seamonkey and it performed the "Addons check" producing a
> list of incompatible addons. These included:-
>
> Seamonkey Debug and QA UI 1.0pre
> Chatzilla 0.9.86
> JavaScript Debugger 0.9.88.1

I see this too.

> The Addons Manager page is not scrollable vertically or horizontally due
> to lack of scroll bars. The same applies to other pages selectable from
> the menu to the left of this page. Looks like another problem found -
> theme in use is Modern.

I don't see that with GrayModern (which isn't supposed to be 
compatible).  It's probably a cross-platform problem with the Modern 
theme.  Only the default theme has platform-specific stuff, to make 
things look more native.

Just did a quick test, and I don't see the problem with Modern, either. 
  I do notice that theme is lacking a lot of polish for newer stuff 
(like the Addons Manager).  That will hopefully improve a lot before the 
2.1 release, but Seamonkey themes have never been given much attention. 
  Now that Personas are supported, I expect that won't change much.
0
Steve
2/11/2011 8:07:00 PM
I have just tried the new Firefox.  I see the following problems:

1.  There is no Status Bar at the bottom of the window, and no option
for it in the View menu, although Firefox continues to write data to
that area, on top of whatever else is already there.

2.  Pop up windows are invisible, although the text is written over top
of whatever is being displayed in the window.

3.  The Previous Page--Next Page buttons in the Navigation Bar are
inoperative.  I am forced to use the History to move back or forward a
page.

4.  This version is very slow as compared to the December beta.

I unzipped to a new directory, but used my current profile.  I did not
see any add-on manager problems as reported for Seamonkey.

Ron


0
Ron
2/11/2011 8:59:57 PM
Ron Klein wrote:

> 1.  There is no Status Bar at the bottom of the window, and no option
> for it in the View menu, although Firefox continues to write data to
> that area, on top of whatever else is already there.

That's not a bug, it's a (cross-platform) feature.  Seriously.  Turning 
on the addon bar might help, and I think people were working on 
extensions to put things back down in there.

> 2.  Pop up windows are invisible, although the text is written over top
> of whatever is being displayed in the window.

What pop up windows?
0
Steve
2/11/2011 9:15:55 PM
On Fri, 11 Feb 2011 13:15:55 -0800, Steve Wendt wrote:

> Ron Klein wrote:
> 
> > 1.  There is no Status Bar at the bottom of the window, and no option
> > for it in the View menu, although Firefox continues to write data to
> > that area, on top of whatever else is already there.
> 
> That's not a bug, it's a (cross-platform) feature.  Seriously.  Turning 
> on the addon bar might help, and I think people were working on 
> extensions to put things back down in there.
> 
> > 2.  Pop up windows are invisible, although the text is written over top
> > of whatever is being displayed in the window.
> 
> What pop up windows?

In the instance I saw, it was a confirmation window, askin if I really
wanted to logout of the site I was visiting.

Ron


0
Ron
2/11/2011 9:47:28 PM
Hi Rich

Rich Walsh wrote:
>
> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.
>


----- snip -----


>
> These releases include a beta version of Exceptq v7.1 to create an
> exception report whenever a crash occurs within the app.  They also
> include debugging files that have a '.xqs' extension.  Please do not
> delete them.  If you don't want these reports to be created, add
> "SET NSPR_NO_EXCEPTQ=Y" to your config.sys.
>
>


Seamonkey crashed while I was looking at the Addons Manager and 
generated a *.trp file. Do you want a copy of this crash report?


Regards

Pete


0
Peter
2/11/2011 9:47:56 PM
Ron Klein wrote:

>>> 2.  Pop up windows are invisible, although the text is written over top
>>> of whatever is being displayed in the window.
>>
>> What pop up windows?
>
> In the instance I saw, it was a confirmation window, askin if I really
> wanted to logout of the site I was visiting.

Is that something site-specific, or something generic to Javascript 
dialogs?  For example, if you paste this into the URL, does it show the 
problem?
javascript:alert('foo!');
0
Steve
2/11/2011 9:52:35 PM
Rich Walsh wrote:

> * Seamonkey v2.1b3pre:

This build seems to stop doing the urlbar autocompletion after it has 
been open for a little while.  Anyone else see that?

It works after restarting, then at some point quits again.  I'm not sure 
if it gets triggered by something I do, or not.
0
Steve
2/11/2011 9:54:44 PM
On Fri, 11 Feb 2011 13:52:35 -0800, Steve Wendt wrote:

> Ron Klein wrote:
> 
> >>> 2.  Pop up windows are invisible, although the text is written over top
> >>> of whatever is being displayed in the window.
> >>
> >> What pop up windows?
> >
> > In the instance I saw, it was a confirmation window, askin if I really
> > wanted to logout of the site I was visiting.
> 
> Is that something site-specific, or something generic to Javascript 
> dialogs?  For example, if you paste this into the URL, does it show the 
> problem?
> javascript:alert('foo!');

This displays the problen, too.

I see the word foo!
  and below it, the OK within a frame.  All displayed on a blank
window.  The animation before the word foo! did not display, nor did
any window frame.

Ron


0
Ron
2/11/2011 10:18:32 PM
On Fri, 11 Feb 2011 13:47:28 -0800 (PST), Ron Klein wrote:

> On Fri, 11 Feb 2011 13:15:55 -0800, Steve Wendt wrote:
> 
> > Ron Klein wrote:
> > 
> > > 1.  There is no Status Bar at the bottom of the window, and no option
> > > for it in the View menu, although Firefox continues to write data to
> > > that area, on top of whatever else is already there.
> > 
> > That's not a bug, it's a (cross-platform) feature.  Seriously.  Turning 
> > on the addon bar might help, and I think people were working on 
> > extensions to put things back down in there.
> > 

Turning on the addon bar does not help.  The information usually
displayed in the status bar is just displayed above the addon bar.  And
if there is no status bar, why is Firefox displaying anything in that
area?

Ron


0
Ron
2/11/2011 10:43:12 PM
Hiya Rich,

On Fri, 11 Feb 2011 13:50:55 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:
> My guess is that 25% of printers don't like Cairo's postscript and
> just blink a bunch but never print.  Change 'use_builtin' to "false"
> and see if it works using the native PS driver.

I think the problem is that pscript.drv adds it's $0.02 to the .ps 
that cairo generates and that confuses some printers...

-- 
Cheers,

Paul.
0
Paul
2/11/2011 10:50:46 PM
Ron Klein wrote:

> Turning on the addon bar does not help.  The information usually
> displayed in the status bar is just displayed above the addon bar.

This might help you:
https://addons.mozilla.org/en-US/firefox/addon/status-4-evar/

> if there is no status bar, why is Firefox displaying anything in that
> area?

Because they copied Chrome.
0
Steve
2/11/2011 10:52:55 PM
Ron Klein wrote:

>> javascript:alert('foo!');
>
> This displays the problen, too.
>
> I see the word foo!
>    and below it, the OK within a frame.  All displayed on a blank
> window.  The animation before the word foo! did not display, nor did
> any window frame.

Sounds like a bug, but I don't use Firefox.  Someone else will have to 
take over commenting on this.
0
Steve
2/11/2011 10:55:40 PM
Hi Pete,

On Fri, 11 Feb 2011 16:29:56 +0000, Peter Brown wrote:

-snip-

>I then started Seamonkey and it performed the "Addons check" producing a 
>list of incompatible addons. These included:-
>
>Seamonkey Debug and QA UI 1.0pre
>Chatzilla 0.9.86
>JavaScript Debugger 0.9.88.1
>
>All of the above are Seamonkey supplied Addons, part of the just 
>unzipped build.
>
>So, something wrong there.
>

 I had the same issue and was able to get around it by deleting the files
'extensions.rdf' and 'extensions.sqlite' from my profile directory. Next
start of SeaMonkey and everything was working.

Regards,

Dave McKenna



0
David
2/11/2011 11:58:54 PM
Rich,

On Fri, 11 Feb 2011 00:23:01 -0600, Rich Walsh wrote:

>
>New betas of Firefox and Seamonkey are now available.  They feature
>the latest Mozilla code plus small refinements to the OS/2 features
>seen in previous betas.
>
>* Firefox v4.0b12pre:
>    ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>  or
>    http://e-vertise.com/warpzilla/firefox-20110210.zip
> 
>* Seamonkey v2.1b3pre:
>    ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>  or
>    http://e-vertise.com/warpzilla/seamonkey-20110210.zip
>
>New
>---
>Printing at 600 dpi is now supported, provided the page requires no
>more than 144mb to compose (an A4- or Letter-sized page uses 132mb
>at 600dpi but only 34mb at 300dpi).
>
>If you use the apps' built-in Postscript support and print directly
>to a PS printer, an experimental option may enable you to use printer
>features such as duplexing. See 'PRINTING.TXT' in the exe's directory
>for details.
>
>SNAP users should no longer experience video corruption caused by the
>mouse pointer when DIVE is enabled.  The apps are now able to detect
>whether SNAP is using a hardware- or software-generated mouse pointer.
>
>These releases include a beta version of Exceptq v7.1 to create an
>exception report whenever a crash occurs within the app.  They also
>include debugging files that have a '.xqs' extension.  Please do not
>delete them.  If you don't want these reports to be created, add
>"SET NSPR_NO_EXCEPTQ=Y" to your config.sys.
>
>
>Previous Enhancements
>---------------------
>Video:  Dramatic reductions in CPU usage will be seen when viewing OGG
>videos, and to a lesser extent, WebM videos.  Overall video performance
>should be noticeably improved for SNAP and GenGradd users running their
>displays in full-color mode, thanks to the implementation of DIVE.
>
>Printing Support:  All native printer drivers will work if their output
>resolution is set to 600 DPI or less.  Mozilla's built-in Postscript
>support is also available for use, as is its PDF support.  Please read
>PRINTING.txt in the exe's directory for details.
>
>Memory Management:  With a few trivial exceptions, the Mozilla apps no
>longer use any shared memory beyond what is needed to load their dlls.
>Problems that have been attributed to low or no shared memory should
>not occur.
>
>Font Selection:  The apps should do a better job of selecting DBCS fonts
>and fonts with less common font weights such as "Thin" or "Heavy".
>
>Copy Link Location: A bug that caused characters to be deleted from URLs
>when using the 'Copy Link Location' menu item has been fixed.
>
>
>Bugs
>----
>Both apps will occasionally "smear" the video when scrolling.  In most
>cases, the easiest workaround is to resize the window slightly to force
>its redisplay.
>
>
>Notes
>-----
>DIVE lets an app bypass PM's graphics subsystem and write directly to
>your video card's memory.  This improves display speed but can cause
>problems on some systems.  Use the following to disable DIVE:
>
>- uncheck "Use hardware acceleration when possible".
>  In Firefox, it's on the Options dialog's 'Advanced->General' tab.
>  In Seamonkey, this is in Preferences under 'Appearance->Content'.
>- start the app in "safe mode" (use "/safe-mode" on the command line)
>- add "SET MOZ_ACCELERATED=0" to config.sys.
>
>
>Support
>-------
>Community support for these betas and all Mozilla apps is available
>through the newsgroups 'mozilla.dev.ports.os2' or 'comp.os.os2.apps'.
>Messages posted to other forums may not be seen by the developers.
>

 Thanks for your continued development of SeaMonkey and Firefox! Up to this
version of your builds, I have been able to print from SeaMonkey using the
'built-in' option to eCUPS, HPeCUPS and PSPrint printers (all to a CUPS port
directed to a CUPS server [on a different eCS machine] which prints to an HP
DeskJet 990C printer attached to an HP DirectJet server). With this new
version, when I try to print to any of these printers SeaMonkey beeps then
crashes (disappears from screen) and a print job is 'stuck' in the spooler
and does not print (*.trp file available if needed).

 I can get the job to print if I either reboot the computer (prints during
boot), or right click on the job in the printer object and select 'Delete'
(immediately prints).

 If I turn the built-in option off and try to print, SeaMonkey crashes like
before, but 2 print jobs are stuck in the spooler (both the same  name).
Neither booting nor deleting gets them to print.

Regards,

Dave McKenna



0
David
2/12/2011 1:00:02 AM
Ron Klein wrote:
> I have just tried the new Firefox.  I see the following problems:
>
> 1.  There is no Status Bar at the bottom of the window, and no option
> for it in the View menu, although Firefox continues to write data to
> that area, on top of whatever else is already there.

It's gone. You can install Status-4-Evar to bring it back. Make sure you 
follow the directions.

>
> 2.  Pop up windows are invisible, although the text is written over top
> of whatever is being displayed in the window.

I think this is working as now designed.

>
> 3.  The Previous Page--Next Page buttons in the Navigation Bar are
> inoperative.  I am forced to use the History to move back or forward a
> page.

This works for me on a couple of day older version. I lost these before 
with an old profile. You could try playing with customize, right click 
on the UI close to the buttons and pick customize. There is also ALT--> 
and ALT-<- (ALT + arrow key) to navigate back and forward.

>
> 4.  This version is very slow as compared to the December beta.

For me they've gotten faster but I don't use Firefox much.
Dave
0
Dave
2/12/2011 1:08:06 AM
Steve Wendt wrote:
> Rich Walsh wrote:
>
>> * Seamonkey v2.1b3pre:
>
> This build seems to stop doing the urlbar autocompletion after it has
> been open for a little while. Anyone else see that?
>
> It works after restarting, then at some point quits again. I'm not sure
> if it gets triggered by something I do, or not.

It's been like that for a while though the build I'm using has been much 
better. I'm using basically the beta 2.
Sometimes I've brought it back by playing in preferences --> location bar.
Dave
0
Dave
2/12/2011 1:11:55 AM
Dave,
Thanks for responding.  I have installed the Status-4-Evar add-on.

I have found that sometimes, when I start Firefox, the back-forward
buttons do work, and also the speed is normal.  Other times, the
buttons do not work, and the speed is horrible  I don't understand the
connection, but it seems to be one or the other.

Thanks,
Ron


On Fri, 11 Feb 2011 17:08:06 -0800, Dave Yeo wrote:

> Ron Klein wrote:
> > I have just tried the new Firefox.  I see the following problems:
> >
> > 1.  There is no Status Bar at the bottom of the window, and no option
> > for it in the View menu, although Firefox continues to write data to
> > that area, on top of whatever else is already there.
> 
> It's gone. You can install Status-4-Evar to bring it back. Make sure you 
> follow the directions.
> 
> >
> > 2.  Pop up windows are invisible, although the text is written over top
> > of whatever is being displayed in the window.
> 
> I think this is working as now designed.
> 
> >
> > 3.  The Previous Page--Next Page buttons in the Navigation Bar are
> > inoperative.  I am forced to use the History to move back or forward a
> > page.
> 
> This works for me on a couple of day older version. I lost these before 
> with an old profile. You could try playing with customize, right click 
> on the UI close to the buttons and pick customize. There is also ALT--> 
> and ALT-<- (ALT + arrow key) to navigate back and forward.
> 
> >
> > 4.  This version is very slow as compared to the December beta.
> 
> For me they've gotten faster but I don't use Firefox much.
> Dave



0
Ron
2/12/2011 1:59:41 AM
On Fri, 11 Feb 2011 20:59:57 UTC, "Ron Klein" <rbklein@earthlink.net> wrote:

> I have just tried the new Firefox.  I see the following problems:
>
> 1.  There is no Status Bar at the bottom of the window, and no option
> for it in the View menu, although Firefox continues to write data to
> that area, on top of whatever else is already there.
>
> 2.  Pop up windows are invisible, although the text is written over top
> of whatever is being displayed in the window.
> 
> 3.  The Previous Page--Next Page buttons in the Navigation Bar are
> inoperative.  I am forced to use the History to move back or forward a
> page.
> 
> 4.  This version is very slow as compared to the December beta.

Any time these mozapps are so totally fubar'd, you can reasonably assume
the problem is local - particularly if the user interface is messed up.

Open your profile directory (with FF closed!) and delete 'XUL.mfl'.  Next,
open the 'startupCache' subdirectory and delete 'startupCache.4.little'.
Now retry.

Point by point...
1) showing the messages that used to be on the status bar in a little
overlay down there strikes me as pretty lame.  I guess people really
didn't like showing that stuff in the address bar like the last beta.

2) javascript popups aren't windows anymore.  Instead, you get a gray
overlay over the entire page area with a framed white box showing the
message.  It looks like a rip-off of the scriptaculous(?) effect that
everyone uses for showing photos.

3 & 4) see above


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/12/2011 2:32:20 AM
On Fri, 11 Feb 2011 17:43:43 UTC, "Dave Saville" wrote:
> On Fri, 11 Feb 2011 14:10:37 UTC, "Rich Walsh" wrote:
> 
> > If you disable DIVE, does the problem go away?  (At the bottom of the
> > announcement are details on how to do this.)
> 
> Is that uncheck the option *and* set the environmental, or either?

Having to do 3 things to turn off one option would be rather much.
Any _one_ will suffice, with "uncheck Use hardware acceleration when
possible" being the preferred action.


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/12/2011 2:38:28 AM
On Fri, 11 Feb 2011 22:50:46 UTC, "Paul Smedley" wrote:
> On Fri, 11 Feb 2011 13:50:55 UTC, "Rich Walsh" wrote:
>
> > My guess is that 25% of printers don't like Cairo's postscript and
> > just blink a bunch but never print.  Change 'use_builtin' to "false"
> > and see if it works using the native PS driver.
> 
> I think the problem is that pscript.drv adds it's $0.02 to the .ps 
> that cairo generates and that confuses some printers...

That's not it.  When you use [print.os2.postscript.use_builtin "true"]
Cairo's output is written directly to the spooler, then sent to the
printer using IBMNULL.  What the printer gets should be byte-for-byte
identical to what Cairo generated.  You can confirm this by comparing
the file that ends up in CUPS' spool directory to a file created using
the app's Print to File option.

What's new in this version is an option to use a postscript driver
rather than ibmnull to move the file from your spool directory to
the printer.  AFAICT, it does *not* change the contents, it simply
prepends the various driver options to the file.  I have no idea
whether this actually works because I don't have a PS printer.

So far, no one has explicitly told me whether it works or not.
Could people who've successfully used the 'built-in' option try
[print.os2.postscript.use_ibmnull "false"] and report whether it:
a) breaks printing
b) prints but doesn't use the options you've set
c) prints and uses the driver's option (e.g. duplexing)


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/12/2011 3:23:43 AM
On 02/11/11 01:23 am, Rich Walsh wrote:

> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.
>
> * Firefox v4.0b12pre:
>      ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>    or
>      http://e-vertise.com/warpzilla/firefox-20110210.zip

The new FF worked the first few times I tried it, but now I get a couple 
of beeps, the mouse pointer disappears (although if I move the invisible 
pointer up to the top of the screen the eCenter pops up), and FF does 
not start.

How do I remedy this? Start with a new profile, or ...?

-=-
Alan
0
Alan
2/12/2011 3:24:45 AM
On Sat, 12 Feb 2011 01:00:02 UTC, "David McKenna" <davidmckenna@comcast.net> wrote:

> Up to this version of your builds, I have been able to print from SeaMonkey
> using the 'built-in' option to eCUPS, HPeCUPS and PSPrint printers [...]
> With this new version, when I try to print to any of these printers SeaMonkey
> beeps then crashes (disappears from screen) and a print job is 'stuck' in the
> spooler and does not print (*.trp file available if needed).

Yes, this is an Exceptq report I'd like to see.  These betas were delayed
when I started getting crashes using printers associated with a PS driver.
The immediate problem was traced to a bug in one of the tools we use to
build the mozapps and had absolutely nothing to do with printing, per se.
Or so we thought...  Please send the report to:  crash@e-vertise.com


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/12/2011 3:32:57 AM
Thanks Rich,
My responses are interspersed at the appropriate points.

On Fri, 11 Feb 2011 20:32:20 -0600, Rich Walsh wrote:

> On Fri, 11 Feb 2011 20:59:57 UTC, "Ron Klein" <rbklein@earthlink.net> wrote:
> 
> > I have just tried the new Firefox.  I see the following problems:
> >
> > 1.  There is no Status Bar at the bottom of the window, and no option
> > for it in the View menu, although Firefox continues to write data to
> > that area, on top of whatever else is already there.
> >
> > 2.  Pop up windows are invisible, although the text is written over top
> > of whatever is being displayed in the window.
> > 
> > 3.  The Previous Page--Next Page buttons in the Navigation Bar are
> > inoperative.  I am forced to use the History to move back or forward a
> > page.
> > 
> > 4.  This version is very slow as compared to the December beta.
> 
> Any time these mozapps are so totally fubar'd, you can reasonably assume
> the problem is local - particularly if the user interface is messed up.
> 
> Open your profile directory (with FF closed!) and delete 'XUL.mfl'.  Next,
> open the 'startupCache' subdirectory and delete 'startupCache.4.little'.
> Now retry.
> 
Did this, and the speed, and back-forward buttons are working--at least
this time.

> Point by point...
> 1) showing the messages that used to be on the status bar in a little
> overlay down there strikes me as pretty lame.  I guess people really
> didn't like showing that stuff in the address bar like the last beta.
> 
The problem is that displaying the messages on top of what is there
already makes them difficult to impossible to read.  I have installed
the Status-4-Evar addon.

> 2) javascript popups aren't windows anymore.  Instead, you get a gray
> overlay over the entire page area with a framed white box showing the
> message.  It looks like a rip-off of the scriptaculous(?) effect that
> everyone uses for showing photos.
> 
Again, there is no gray overlay, or box around the message.  Same as
above--very difficult to impossible to read.  It appears to be a
javascript problem.

Thanks,
Ron
> 
> 
> -- 
> == == almost usable email address:  Rich AT E-vertise.Com == ==
> 



0
Ron
2/12/2011 3:36:00 AM
On 02/11/11 11:15 am, Peter Brown wrote:
>> I'll give the "backup Profile and delete files addons.* and
>> extensions.*" a go and report back.
>>
>
>
> With Seamonkey not running I copied all addons.* and extensions.* files
> to new filenames.
>
> I then started Seamonkey with this Profile (losepete).
>
> Opening the Addons Manager I see that nearly all of my Addons that were
> previously "incompatible" - both Seamonkey supplied and those added
> myself - are now Compatible. There is 1 Seamonkey supplied addon that is
> still "incompatible" though: DOM Inspector 2.0.8 is incompatible with
> Seamonkey 2.1b3pre and shows (disabled).
>
> It does now have a Remove button though so gave removing it a try. After
> clicking Remove there was no message about needing to Restart Seamonkey.
>
> I restarted Seamonkey and checked the Addons Manager again. This told me
> "DOM Inspector will be enabled after you restart Seamonkey" and there is
> a Restart Now button which I clicked. Hmmm... that did a lot of good as
> the reloaded page says exactly the same thing. However I see there is a
> Disable button despite the fact that the addon is shown as Disabled -
> not sure if this button showed on the first attempt...
>
> I clicked Disable and the button changed to Enable - no option to
> Restart Now.
>
> I clicked Enable and the Restart Now option reappeared so I clicked that.
>
> After restart the DOM Inspector shows as working; ie there is no
> "incompatible" message, it is not shown as Disabled and a Disable button
> exists.
>
>
> What a lot of performance to get the standard Seamonkey supplied addons
> "compatible" and Enabled... especially if you have several Profiles all
> with the same problem.
>
> I guess something in the Profiles addons.* and/or extensions.* files
> causes the Addons Checker to declare *compatible* addons as "incompatible".
>
>
> Now to see if I can get my 1 remaining not-Seamonkey-supplied
> incompatible addon, British English Dictionary 1.19.1, to be compatible
> and enabled.
>
> That was easy - simply Remove, restart Seamonkey, drag'n'drop the xpi
> file onto Seamonkey, install, Restart, check Addons Manager - and,
> voila! Dictionary installed and Enabled.
>
>
> Should I re-visit my bugzilla bug and file a report on the
> "incompatible" Seamonkey supplied addons and what steps I took to get
> them "compatible" and Enabled?

I think if anything is added to the bug it should be the minimum. Dave 
McKenna seems to have narrowed it down to 2 files. Perhaps add them to 
the bug after testing with one of your profiles.
Dave
0
Dave
2/12/2011 4:13:40 AM
On Sat, 12 Feb 2011 03:24:45 UTC, Alan Beagley wrote:
> On 02/11/11 01:23 am, Rich Walsh wrote:
> 
> The new FF worked the first few times I tried it, but now I get a couple 
> of beeps, the mouse pointer disappears (although if I move the invisible 
> pointer up to the top of the screen the eCenter pops up), and FF does 
> not start.
> 
> How do I remedy this? Start with a new profile, or ...?

Since it appears to be video or mouse related, try one of the first two
to get it going, then use the third to make it permanent:

- start the app in "safe mode" (use "/safe-mode" on the command line)
- add "SET MOZ_ACCELERATED=0" to config.sys.
- uncheck "Use hardware acceleration when possible".
  In Firefox, it's on the Options dialog's 'Advanced->General' tab.
  In Seamonkey, this is in Preferences under 'Appearance->Content'.

Did you try the previous beta (20101204)?  If so, did you have a
similar problem?  Also, what video card and driver are you using
(i.e. SNAP, Panorama, GenGradd...)?


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/12/2011 5:25:37 AM
Rich Walsh wrote:

> * Seamonkey v2.1b3pre:

FWIW, this link from a discussion on the newsgroups reliably causes a 
crash here:

http://www.gnu.org/software/grub/manual/grub.html#Installing-GRUB-using-grub_002dinstall

Interestingly enough, it isn't always the same trap, but it is mostly 
this one:

166117FB   XUL       0001:004217FB  between 
mozilla::places::History::RegisterVisitedCallback + 17F and 
mozilla::places::History::SetURITitle - 1C9  (both in History.o)
0
Steve
2/12/2011 6:29:31 AM
Dave Yeo wrote:

>> This build seems to stop doing the urlbar autocompletion after it has
>> been open for a little while. Anyone else see that?
>
> It's been like that for a while though the build I'm using has been much
> better. I'm using basically the beta 2.

Thanks for confirming...

> Sometimes I've brought it back by playing in preferences --> location bar.

I tried that, but it didn't seem to help.
0
Steve
2/12/2011 6:44:22 AM
Rich Walsh wrote:

> Could people who've successfully used the 'built-in' option try
> [print.os2.postscript.use_ibmnull "false"] and report whether it:
> a) breaks printing
> b) prints but doesn't use the options you've set
> c) prints and uses the driver's option (e.g. duplexing)

I tried printing in landscape mode.  With use_builtin and use_ibmnull 
both false, I get landscape.  With use_builtin true and use_ibmnull 
false, I get portrait mode.

All combinations print something, as far as I can tell.  This is 
pscript.drv 30.827, configured for a "HP LaserJet 4/4M Plus PS 300", and 
printing on a HP LaserJet 4250n.
0
Steve
2/12/2011 7:01:43 AM
On 02/11/11 10:29 pm, Steve Wendt wrote:
> Rich Walsh wrote:
>
>> * Seamonkey v2.1b3pre:
>
> FWIW, this link from a discussion on the newsgroups reliably causes a
> crash here:
>
> http://www.gnu.org/software/grub/manual/grub.html#Installing-GRUB-using-grub_002dinstall
>
>
> Interestingly enough, it isn't always the same trap, but it is mostly
> this one:
>
> 166117FB XUL 0001:004217FB between
> mozilla::places::History::RegisterVisitedCallback + 17F and
> mozilla::places::History::SetURITitle - 1C9 (both in History.o)

While I had no problem visiting the above link, the crash you mention is 
the most common one I have by far, followed by fontmetrics related 
crashes (seem to happen after the system has been up for a while) and 
occasionally an image related one. Also a few one offs.
The places one is usually random when loading a tab but occasionally I 
have had to give up loading a link like yours above.
These sporadic crashes are the hardest to debug and I wonder how much 
might be due to sqlite3 database corruption.
The biggest problem is a shortage of developers, really there is just 
Rich and he has a lot on his plate. Walter and I can take a bit of the 
load off of him but we need more coding experts.
Dave



0
Dave
2/12/2011 7:16:09 AM
Steve Wendt wrote:

> All combinations print something, as far as I can tell. This is
> pscript.drv 30.827, configured for a "HP LaserJet 4/4M Plus PS 300", and
> printing on a HP LaserJet 4250n.

I get the best quality using "use_builtin" and "use_ibmnull" both set to 
true.  With "use_ibmnull" set to false, I get a lot of stippled lines 
and bad looking text (perhaps this is due to some bad PS driver 
settings; I hardly ever print anything).  With "use_builtin" set to 
false, things like form fields are unreadable - this is probably related 
to the 96dpi display problems.
0
Steve
2/12/2011 7:17:08 AM
David McKenna wrote:

>> I then started Seamonkey and it performed the "Addons check" producing a
>> list of incompatible addons. These included:-
>>
>> Seamonkey Debug and QA UI 1.0pre
>> Chatzilla 0.9.86
>> JavaScript Debugger 0.9.88.1
>
>   I had the same issue and was able to get around it by deleting the files
> 'extensions.rdf' and 'extensions.sqlite' from my profile directory. Next
> start of SeaMonkey and everything was working.

The extensions.rdf is obsolete, so that doesn't matter.  Deleting 
extensions.sqlite and letting it rebuild fixes the above three, and 
causes the DOM Inspector one to say it is incompatible instead.  That's 
pretty much the same behavior I saw before.
https://bugzilla.mozilla.org/show_bug.cgi?id=609524#c2
0
Steve
2/12/2011 7:25:39 AM
Steve Wendt wrote:
> Dave Yeo wrote:
>
>>> This build seems to stop doing the urlbar autocompletion after it has
>>> been open for a little while. Anyone else see that?
>>
>> It's been like that for a while though the build I'm using has been much
>> better. I'm using basically the beta 2.
>
> Thanks for confirming...
>
>> Sometimes I've brought it back by playing in preferences --> location
>> bar.
>
> I tried that, but it didn't seem to help.

Yea, it only seemed to work when the problem first manifested.
It also seemed to be related to the number of tabs open. Lots of open 
tabs then if I opened a blank one it seemed to start. I haven't 
researched this very much though.
Dave
0
Dave
2/12/2011 7:28:07 AM
Dave Yeo wrote:

>>>> This build seems to stop doing the urlbar autocompletion after it has
>>>> been open for a little while. Anyone else see that?
>
> It also seemed to be related to the number of tabs open. Lots of open
> tabs then if I opened a blank one it seemed to start.

No tabs open when I've seen it here, just the single window.  I'm sure I 
had a few tabs open before that, though (but not very many at once, 
maybe 3 or 4).
0
Steve
2/12/2011 7:32:14 AM
On Fri, 11 Feb 2011 21:54:44 UTC, Steve Wendt <spamsux@forgetit.org> 
wrote:

> Rich Walsh wrote:
> 
> > * Seamonkey v2.1b3pre:
> 
> This build seems to stop doing the urlbar autocompletion after it has 
> been open for a little while.  Anyone else see that?

I saw that yesterday. I copied places.sqlite from backup and it worked 
since. 


-- 
Hessu
Feel free to correct my English :-)
0
Heikki
2/12/2011 9:44:51 AM
On Sat, 12 Feb 2011 02:38:28 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Fri, 11 Feb 2011 17:43:43 UTC, "Dave Saville" wrote:
> > On Fri, 11 Feb 2011 14:10:37 UTC, "Rich Walsh" wrote:
> > 
> > > If you disable DIVE, does the problem go away?  (At the bottom of the
> > > announcement are details on how to do this.)
> > 
> > Is that uncheck the option *and* set the environmental, or either?
> 
> Having to do 3 things to turn off one option would be rather much.
> Any _one_ will suffice, with "uncheck Use hardware acceleration when
> possible" being the preferred action.
> 
> 

Well it's not that clear - and it makes no difference. Still get the 
square "holes" in the page. Seems to happen more often when the mouse 
is moved before the page is fully rendered. But not always.

WRT "hangs" with high CPU. This would appear to be page rendering. I 
read a lot of SF from 
http://www.gutenberg.org/wiki/Science_Fiction_%28Bookshelf%29 
the books tend to be one large HTML file, several hundred Kbyte in 
some cases, maybe with a b/w drawing but even so  99% plain text. FF 
connects and the status says "Transferring from ......." but there is 
no activity on the network switch. The top of the page is (partially) 
rendered and it just sits there. Nothing is usable, only the mouse 
moves. Until one finally gets control back when the page redraws and 
the vertical slider sorts itself out. This can easily take over 30 
seconds. Does FF render the entire page in RAM first? This is on a T23
with 600 Mb. In the rare instances that I can get some monitor up it 
is not using all the memory and no swap activity. Just 100% CPU burn. 
:-(

-- 
Regards
Dave Saville
0
Dave
2/12/2011 12:04:21 PM
On Sat, 12 Feb 2011 12:04:21 UTC, "Dave Saville" 
<dave@invalid.invalid> wrote:

> On Sat, 12 Feb 2011 02:38:28 UTC, "Rich Walsh" 
> <spamyourself@127.0.0.1> wrote:
> 
> > On Fri, 11 Feb 2011 17:43:43 UTC, "Dave Saville" wrote:
> > > On Fri, 11 Feb 2011 14:10:37 UTC, "Rich Walsh" wrote:
> > > 
> > > > If you disable DIVE, does the problem go away?  (At the bottom of the
> > > > announcement are details on how to do this.)
> > > 
> > > Is that uncheck the option *and* set the environmental, or either?
> > 
> > Having to do 3 things to turn off one option would be rather much.
> > Any _one_ will suffice, with "uncheck Use hardware acceleration when
> > possible" being the preferred action.
> > 
> > 
> 
> Well it's not that clear - and it makes no difference. Still get the 
> square "holes" in the page. Seems to happen more often when the mouse 
> is moved before the page is fully rendered. But not always.
> 
> WRT "hangs" with high CPU. This would appear to be page rendering. I 
> read a lot of SF from 
> http://www.gutenberg.org/wiki/Science_Fiction_%28Bookshelf%29 
> the books tend to be one large HTML file, several hundred Kbyte in 
> some cases, maybe with a b/w drawing but even so  99% plain text. FF 
> connects and the status says "Transferring from ......." but there is 
> no activity on the network switch. The top of the page is (partially) 
> rendered and it just sits there. Nothing is usable, only the mouse 
> moves. Until one finally gets control back when the page redraws and 
> the vertical slider sorts itself out. This can easily take over 30 
> seconds. Does FF render the entire page in RAM first? This is on a T23
> with 600 Mb. In the rare instances that I can get some monitor up it 
> is not using all the memory and no swap activity. Just 100% CPU burn. 
> :-(
> 

I just tried http://www.gutenberg.org/files/19066/19066-h/19066-h.htm 
Took well over a minute. Tried on my T42 with 1 Meg RAM under Ubuntu 
with FF 3.6.13 - about 2 seconds. There is not that much difference in
speed between the two boxes. 
-- 
Regards
Dave Saville
0
Dave
2/12/2011 12:19:48 PM
On Sat, 12 Feb 2011 03:24:45 UTC in mozilla.dev.ports.os2, Alan Beagley 
<cyberpastor@charter.net> wrote:

> now I get a couple 
> of beeps, the mouse pointer disappears (although if I move the invisible 
> pointer up to the top of the screen the eCenter pops up)

It always used to be the case the the IBM e.exe editor was very good at 
retrieving lost mice pointers - just start it up and close it down and it does 
its magic and the mouse is restored.... usually.

-- 
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
0
Trevor
2/12/2011 1:26:54 PM
On Sat, 12 Feb 2011 12:19:48 UTC, "Dave Saville" <dave@invalid.invalid> 
wrote:

> I just tried http://www.gutenberg.org/files/19066/19066-h/19066-h.htm 
> Took well over a minute. Tried on my T42 with 1 Meg RAM under Ubuntu 
> with FF 3.6.13 - about 2 seconds. There is not that much difference in
> speed between the two boxes. 

Seamonkey (rv:2.0b12pre Gecko/20110210) about 20 seconds on 700 MHz 
Celeron 512 KB ram.

-- 
Hessu
Feel free to correct my English :-)
0
Heikki
2/12/2011 2:13:51 PM
On Sat, 12 Feb 2011 14:13:51 UTC, "Heikki Kekki" <kekkihei@sgic.fi.invalid> 
wrote:

> On Sat, 12 Feb 2011 12:19:48 UTC, "Dave Saville" <dave@invalid.invalid> 
> wrote:
> 
> > I just tried http://www.gutenberg.org/files/19066/19066-h/19066-h.htm 
> > Took well over a minute. Tried on my T42 with 1 Meg RAM under Ubuntu 
> > with FF 3.6.13 - about 2 seconds. There is not that much difference in
> > speed between the two boxes. 
> 
> Seamonkey (rv:2.0b12pre Gecko/20110210) about 20 seconds on 700 MHz 
> Celeron 512 KB ram.

Latest Firefox drop, about 2 secs on my Phenom II - 2 core, 3.2Gig...
0
Dariusz
2/12/2011 4:00:06 PM
On Sat, 12 Feb 2011 12:04:21 UTC, "Dave Saville" wrote:
> On Sat, 12 Feb 2011 02:38:28 UTC, "Rich Walsh" wrote:
> 
> > > > If you disable DIVE, does the problem go away?  (At the bottom
> > > > of the announcement are details on how to do this.)
> >
> > Any _one_ will suffice, with "uncheck Use hardware acceleration when
> > possible" being the preferred action.
> 
> it makes no difference. Still get the square "holes" in the page

If you unchecked "Use hardware acceleration" then you're right:
it doesn't do anything.  They changed the name of the preference
associated with this checkbox.  Until this is fixed, add this to
your environment:

  SET MOZ_ACCELERATED=0

> WRT "hangs" with high CPU. This would appear to be page rendering.

Is this different than previous versions, especially previous betas?
If so, see if disabling DIVE makes a difference.

BTW... if there's any question as to DIVE's status and operation,
redirect stdout to a log file, e.g. firefox 2>&1 ff.log
The first few lines will show whether it's enabled, and for SNAP,
whether it will hide the mouse pointer during screen updates.

-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==

0
Rich
2/12/2011 4:32:22 PM
On Sat, 12 Feb 2011 16:32:22 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Sat, 12 Feb 2011 12:04:21 UTC, "Dave Saville" wrote:
> > On Sat, 12 Feb 2011 02:38:28 UTC, "Rich Walsh" wrote:
> > 
> > > > > If you disable DIVE, does the problem go away?  (At the bottom
> > > > > of the announcement are details on how to do this.)
> > >
> > > Any _one_ will suffice, with "uncheck Use hardware acceleration when
> > > possible" being the preferred action.
> > 
> > it makes no difference. Still get the square "holes" in the page
> 
> If you unchecked "Use hardware acceleration" then you're right:
> it doesn't do anything.  They changed the name of the preference
> associated with this checkbox.  Until this is fixed, add this to
> your environment:
> 
>   SET MOZ_ACCELERATED=0
> 

OK done that.

> > WRT "hangs" with high CPU. This would appear to be page rendering.
> 
> Is this different than previous versions, especially previous betas?

At least the last three betas, including this, have been slow. I 
really can't recall before that.

> If so, see if disabling DIVE makes a difference.
>

OK - done that. Will see.
 
> BTW... if there's any question as to DIVE's status and operation,
> redirect stdout to a log file, e.g. firefox 2>&1 ff.log

You missed a >     2>&1>ff.log

> The first few lines will show whether it's enabled, and for SNAP,
> whether it will hide the mouse pointer during screen updates.
> 

[T:\tmp]cat ff.log
en/ex os2Printers
DIVE is disabled - MOZ_ACCELERATED=0

Is all I get. I assume the hide mouse thing is with dive enabled?

-- 
Regards
Dave Saville
0
Dave
2/12/2011 4:56:52 PM
On Sat, 12 Feb 2011 16:32:22 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> > WRT "hangs" with high CPU. This would appear to be page rendering.
> 
> Is this different than previous versions, especially previous betas?
> If so, see if disabling DIVE makes a difference.

If anything on a few tests it seems worse - 4 minutes 31 seconds to 
load a 500K page. :-( *And* I dropped it to only the one tab and 
restarted FF in case that had a bearing on things.
-- 
Regards
Dave Saville
0
Dave
2/12/2011 5:21:35 PM
On Sat, 12 Feb 2011 03:32:57 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Sat, 12 Feb 2011 01:00:02 UTC, "David McKenna" <davidmckenna@comcast.net> wrote:
> 
> > Up to this version of your builds, I have been able to print from SeaMonkey
> > using the 'built-in' option to eCUPS, HPeCUPS and PSPrint printers [...]
> > With this new version, when I try to print to any of these printers SeaMonkey
> > beeps then crashes (disappears from screen) and a print job is 'stuck' in the
> > spooler and does not print (*.trp file available if needed).
> 
> Yes, this is an Exceptq report I'd like to see.  These betas were delayed
> when I started getting crashes using printers associated with a PS driver.
> The immediate problem was traced to a bug in one of the tools we use to
> build the mozapps and had absolutely nothing to do with printing, per se.
> Or so we thought...  Please send the report to:  crash@e-vertise.com
> 
> 
I was just testing printing with
print.os2.postscript.use_builtin "true"
print.os2.postscript.use_ibmnull "false"

and had the same thing occur... crash with hung print job.  The crash 
report says attempt to write to  uncommitted memory allocated by 
DOSCALL1.
I can send this report if it is beneficial.  As well as the PS output 
in the spooler if that would help.
So far I have had only one other crash and it was when I was in 
Preferences - Helper applications while scrolling through them I got a
crash due when xul.dll tried to read from invalid memory.

Andy
-- 

0
Andy
2/12/2011 6:31:50 PM
On Sat, 12 Feb 2011 18:31:50 UTC, "Andy" wrote:
> On Sat, 12 Feb 2011 03:32:57 UTC, "Rich Walsh" wrote:
> > On Sat, 12 Feb 2011 01:00:02 UTC, "David McKenna" wrote:
> > 
> > > With this new version, when I try to print to any of these printers
> > > SeaMonkey beeps then crashes (disappears from screen) and a print job
> > > is 'stuck' in the spooler and does not print
> > 
> > I started getting crashes using printers associated with a PS driver.
> > 
> I was just testing printing with
> print.os2.postscript.use_builtin "true"
> print.os2.postscript.use_ibmnull "false"
> 
> and had the same thing occur... crash with hung print job.  The crash 
> report says attempt to write to  uncommitted memory allocated by 
> DOSCALL1.

Dave's trap report shows the exact same problem I was having but "cured"
when we worked around the bug in one of our tools (emxomfld).

Do you get a trap if 'use_ibmnull' is set to "true"?  I did.

> I can send this report if it is beneficial.  As well as the PS output 
> in the spooler if that would help.

Yes, please send all of it.  Of particular interest is the '.shd' file
associated with that print job.  My guess is that the crash occurs when
it is either being created or used by the system.  (FWIW... the crash
doesn't come until Moz is completely done generating the PS and the OS/2
code is closing the spooler.)


-- 
== == 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/
___________________________________________________________________

0
Rich
2/12/2011 9:25:43 PM
On Sat, 12 Feb 2011 21:25:43 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Sat, 12 Feb 2011 18:31:50 UTC, "Andy" wrote:
> > On Sat, 12 Feb 2011 03:32:57 UTC, "Rich Walsh" wrote:
> > > On Sat, 12 Feb 2011 01:00:02 UTC, "David McKenna" wrote:
> > > 
> > > > With this new version, when I try to print to any of these printers
> > > > SeaMonkey beeps then crashes (disappears from screen) and a print job
> > > > is 'stuck' in the spooler and does not print
> > > 
> > > I started getting crashes using printers associated with a PS driver.
> > > 
> > I was just testing printing with
> > print.os2.postscript.use_builtin "true"
> > print.os2.postscript.use_ibmnull "false"
> > 
> > and had the same thing occur... crash with hung print job.  The crash 
> > report says attempt to write to  uncommitted memory allocated by 
> > DOSCALL1.
> 
> Dave's trap report shows the exact same problem I was having but "cured"
> when we worked around the bug in one of our tools (emxomfld).
> 
> Do you get a trap if 'use_ibmnull' is set to "true"?  I did.
> 
> > I can send this report if it is beneficial.  As well as the PS output 
> > in the spooler if that would help.
> 
> Yes, please send all of it.  Of particular interest is the '.shd' file
> associated with that print job.  My guess is that the crash occurs when
> it is either being created or used by the system.  (FWIW... the crash
> doesn't come until Moz is completely done generating the PS and the OS/2
> code is closing the spooler.)
> 
> 
The progress dialog is at 50% when it crashes... the job status shows 
spooling.  I am not finding a .shd file, I presume it should be in the
spooler directory as I did find some older shd files in another spool 
directory from September.  There is only the spl file there.  I will 
send it and the trp file.  I have reproduced the crash three time so 
far (though the second time it did not create a trp file despite 
getting the beeps).  
Actually it doesn't matter which option I choose it crashes, and I 
even removed the prefs entirely and it crashes when printing here.  
The previous versions printed fine to the same printer (Brother 
7820N).
I sent the files but I am not 100% they went out as Seamonkey froze at
the end of the send process.
Andy
-- 

0
Andy
2/13/2011 1:04:32 AM
Steve,

On Fri, 11 Feb 2011 23:25:39 -0800, Steve Wendt wrote:

>The extensions.rdf is obsolete, so that doesn't matter.  

  OK... didn't know that. Are there any other obsolete things you know of
that may be lurking in my profile?

>Deleting 
>extensions.sqlite and letting it rebuild fixes the above three, and 
>causes the DOM Inspector one to say it is incompatible instead.  That's 
>pretty much the same behavior I saw before.
>https://bugzilla.mozilla.org/show_bug.cgi?id=609524#c2

 Hmm... yeah I didn't notice that before. I removed DOM inspector and after
restarting SeaMonkey, it is listed as 'disabled' and 'will be enabled after
you restart SeaMonkey' but it never gets enabled.... strange.

Dave McKenna



0
David
2/13/2011 2:55:45 AM
Hi Dave

David McKenna wrote:
> Steve,
>
> On Fri, 11 Feb 2011 23:25:39 -0800, Steve Wendt wrote:
>
>> The extensions.rdf is obsolete, so that doesn't matter.
>
>    OK... didn't know that. Are there any other obsolete things you know of
> that may be lurking in my profile?
>
>> Deleting
>> extensions.sqlite and letting it rebuild fixes the above three, and
>> causes the DOM Inspector one to say it is incompatible instead.  That's
>> pretty much the same behavior I saw before.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=609524#c2
>
>   Hmm... yeah I didn't notice that before. I removed DOM inspector and after
> restarting SeaMonkey, it is listed as 'disabled' and 'will be enabled after
> you restart SeaMonkey' but it never gets enabled.... strange.
>
> Dave McKenna
>
>
>


I saw this very recently:-

If it still has the Disabled button click it and it should change to an 
Enable button. Click that and the Restart Now option should appear, 
click it and then check if it is Enabled.

Regards

Pete

0
Peter
2/13/2011 3:12:39 AM
David McKenna wrote:

>> The extensions.rdf is obsolete, so that doesn't matter.
>
>    OK... didn't know that. Are there any other obsolete things you know of
> that may be lurking in my profile?

Probably... over time, they have transitioned various files to new 
formats.  Generally speaking, RDF is dead, and SQLite is the new data 
format.
0
Steve
2/13/2011 3:42:23 AM
I have just spent some time with Only FF running and only using one 
tab.

I downloaded one of the ebooks to local (JFS) drive.
Test sequence is:

Display home page. 
Clear cache
load ebook.
Repeat

In general without DIVE tends to give longer times.

DIVE: Shortest 12secs, Longest 2 minutes 30 secs
NoDIVE: Shortest 11secs, Longest 4 minutes

Same number of tests each way (12) and NoDive has twice as many one 
minute or more. During the test I have 360+ Mb free. Does not waver. 
Swap sits at 2Mb. *sometimes* the C drive icon on the xcenter drive 
display hashes so maybe the odd page is written to swap. Problem is I 
can't find anything to run that constantly updates and tells me what's
going on. Thesus only appears to give on demand displays which is no 
good because nothing responds until FF finishes doing whatever the 
hell it is doing to burn that much CPU.

The only advantage I can see of turning DIVE off is the black hole 
under the mouse seems not to occur.
-- 
Regards
Dave Saville
0
Dave
2/13/2011 9:20:01 AM
Pete,

On Sun, 13 Feb 2011 03:12:39 +0000, Peter Brown wrote:

>Hi Dave
>
>David McKenna wrote:
>> Steve,
>>
>> On Fri, 11 Feb 2011 23:25:39 -0800, Steve Wendt wrote:
>>
>>> The extensions.rdf is obsolete, so that doesn't matter.
>>
>>    OK... didn't know that. Are there any other obsolete things you know of
>> that may be lurking in my profile?
>>
>>> Deleting
>>> extensions.sqlite and letting it rebuild fixes the above three, and
>>> causes the DOM Inspector one to say it is incompatible instead.  That's
>>> pretty much the same behavior I saw before.
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=609524#c2
>>
>>   Hmm... yeah I didn't notice that before. I removed DOM inspector and after
>> restarting SeaMonkey, it is listed as 'disabled' and 'will be enabled after
>> you restart SeaMonkey' but it never gets enabled.... strange.
>>
>> Dave McKenna
>>
>>
>>
>
>
>I saw this very recently:-
>
>If it still has the Disabled button click it and it should change to an 
>Enable button. Click that and the Restart Now option should appear, 
>click it and then check if it is Enabled.
>

  Thanks, that fixed it!

Regards,

Dave McKenna



0
David
2/13/2011 3:10:07 PM
On Sat, 12 Feb 2011 03:23:43 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:

> On Fri, 11 Feb 2011 22:50:46 UTC, "Paul Smedley" wrote:
> > On Fri, 11 Feb 2011 13:50:55 UTC, "Rich Walsh" wrote:
> >
> > > My guess is that 25% of printers don't like Cairo's postscript and
> > > just blink a bunch but never print.  Change 'use_builtin' to "false"
> > > and see if it works using the native PS driver.
> > 
> > I think the problem is that pscript.drv adds it's $0.02 to the .ps 
> > that cairo generates and that confuses some printers...
> 
> That's not it.  When you use [print.os2.postscript.use_builtin "true"]
> Cairo's output is written directly to the spooler, then sent to the
> printer using IBMNULL.  What the printer gets should be byte-for-byte
> identical to what Cairo generated.  You can confirm this by comparing
> the file that ends up in CUPS' spool directory to a file created using
> the app's Print to File option.
> 
> What's new in this version is an option to use a postscript driver
> rather than ibmnull to move the file from your spool directory to
> the printer.  AFAICT, it does *not* change the contents, it simply
> prepends the various driver options to the file.  I have no idea
> whether this actually works because I don't have a PS printer.
> 
> So far, no one has explicitly told me whether it works or not.
> Could people who've successfully used the 'built-in' option try
> [print.os2.postscript.use_ibmnull "false"] and report whether it:
> a) breaks printing
> b) prints but doesn't use the options you've set
> c) prints and uses the driver's option (e.g. duplexing)

Rich,
Here are the tests I ran...hopefully this answers your question above...my 
printer is a Brother HL-1650 (networked through a built-in NIC print server), 
printer has 128MB cache and I am printing to it through SLPR port using 
'LPRPROTD Compatible' mode:

RUN_ID	built-in		ibmnull		DPI	DUPLEX	SIZE		RESULT
1	FALSE		FALSE		300	YES	3843K		Prints OK, low quality, takes long, duplex OK.
2	FALSE		FALSE		600	YES	12217K		Prints OK, quality OK, takes longer, duplex OK.
3	FALSE		TRUE		600	YES	12217K		Prints OK, quality same as #3, takes longer, 
duplex OK.
4	TRUE		TRUE		600	YES	625k		Prints OK, best quality, fairly quick, no duplex.
5	TRUE		FALSE		600	YES	625K		Prints OK, slightly worse quality then #4, but 
better then #3, duplex OK.
6	TRUE		FALSE		1200	YES	625K		Prints OK, best quality, same as #4, fairly quick,
duplex OK.

I was printing 2 pages from my eBay account summary page...so a mix of layout, 
some graphics and text.

Overall, #5 & 6 settings are by far producing the best combination of output 
quality and printer feature support. The fact that I am getting DUPLEX print 
output is what I am particularly happy about. Prints #1 through #3 took 
extremely long though...obviously these spool files are larger, but 
still...compared to some other print jobs these ones took 'forever'...LOL.

The only strange thing is that whereas #5 job was @ 600 DPI and it's SPOOL size 
was 625K, #6 was a 1200 DPI job but it's spool size was also 625K...however the 
real output of #6 is noticeably better, and it certainly is the 1200 DPI that I 
would normally get out of the printer for other non-Firefox print jobs.

I did notice a few other 'quirks' about this release, but I'll post in response 
to one of the other comments where it's more appropriate.

Thanks again (as always) for a fantastic job on this port...much appreciated!
0
Dariusz
2/13/2011 4:03:33 PM
On Sun, 13 Feb 2011 16:03:33 UTC, "Dariusz Piatkowski" 
<dariusz@_NO-SPAM_mnsi.net> wrote:

> On Sat, 12 Feb 2011 03:23:43 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:
> 
> > On Fri, 11 Feb 2011 22:50:46 UTC, "Paul Smedley" wrote:
> > > On Fri, 11 Feb 2011 13:50:55 UTC, "Rich Walsh" wrote:
> > >
> > > > My guess is that 25% of printers don't like Cairo's postscript and
> > > > just blink a bunch but never print.  Change 'use_builtin' to "false"
> > > > and see if it works using the native PS driver.
> > > 
> > > I think the problem is that pscript.drv adds it's $0.02 to the .ps 
> > > that cairo generates and that confuses some printers...
> > 
> > That's not it.  When you use [print.os2.postscript.use_builtin "true"]
> > Cairo's output is written directly to the spooler, then sent to the
> > printer using IBMNULL.  What the printer gets should be byte-for-byte
> > identical to what Cairo generated.  You can confirm this by comparing
> > the file that ends up in CUPS' spool directory to a file created using
> > the app's Print to File option.
> > 
> > What's new in this version is an option to use a postscript driver
> > rather than ibmnull to move the file from your spool directory to
> > the printer.  AFAICT, it does *not* change the contents, it simply
> > prepends the various driver options to the file.  I have no idea
> > whether this actually works because I don't have a PS printer.
> > 
> > So far, no one has explicitly told me whether it works or not.
> > Could people who've successfully used the 'built-in' option try
> > [print.os2.postscript.use_ibmnull "false"] and report whether it:
> > a) breaks printing
> > b) prints but doesn't use the options you've set
> > c) prints and uses the driver's option (e.g. duplexing)
> 
> Rich,
> Here are the tests I ran...hopefully this answers your question above...my 
> printer is a Brother HL-1650 (networked through a built-in NIC print server), 
> printer has 128MB cache and I am printing to it through SLPR port using 
> 'LPRPROTD Compatible' mode:
> 
> RUN_ID	built-in		ibmnull		DPI	DUPLEX	SIZE		RESULT
> 1	FALSE		FALSE		300	YES	3843K		Prints OK, low quality, takes long, duplex OK.
> 2	FALSE		FALSE		600	YES	12217K		Prints OK, quality OK, takes longer, duplex OK.
> 3	FALSE		TRUE		600	YES	12217K		Prints OK, quality same as #3, takes longer, 
> duplex OK.
> 4	TRUE		TRUE		600	YES	625k		Prints OK, best quality, fairly quick, no duplex.
> 5	TRUE		FALSE		600	YES	625K		Prints OK, slightly worse quality then #4, but 
> better then #3, duplex OK.
> 6	TRUE		FALSE		1200	YES	625K		Prints OK, best quality, same as #4, fairly quick,
> duplex OK.
> 
> I was printing 2 pages from my eBay account summary page...so a mix of layout, 
> some graphics and text.
> 
> Overall, #5 & 6 settings are by far producing the best combination of output 
> quality and printer feature support. The fact that I am getting DUPLEX print 
> output is what I am particularly happy about. Prints #1 through #3 took 
> extremely long though...obviously these spool files are larger, but 
> still...compared to some other print jobs these ones took 'forever'...LOL.
> 
> The only strange thing is that whereas #5 job was @ 600 DPI and it's SPOOL size 
> was 625K, #6 was a 1200 DPI job but it's spool size was also 625K...however the 
> real output of #6 is noticeably better, and it certainly is the 1200 DPI that I 
> would normally get out of the printer for other non-Firefox print jobs.
> 
> I did notice a few other 'quirks' about this release, but I'll post in response 
> to one of the other comments where it's more appropriate.
> 
> Thanks again (as always) for a fantastic job on this port...much appreciated!

....totally forgot to mention that the printer is obviously Postscript capable, 
using 30.792 driver...
0
Dariusz
2/13/2011 4:05:45 PM
Steve,

On Sat, 12 Feb 2011 19:42:23 -0800, Steve Wendt wrote:

>David McKenna wrote:
>
>>> The extensions.rdf is obsolete, so that doesn't matter.
>>
>>    OK... didn't know that. Are there any other obsolete things you know of
>> that may be lurking in my profile?
>
>Probably... over time, they have transitioned various files to new 
>formats.  Generally speaking, RDF is dead, and SQLite is the new data 
>format.

  Thanks... this spurred me on to looking at my profile and getting rid of
what appeared (by the dates) to be old stuff clogging it. After deleting
things SeaMonkey seems to be more stable - especially after removing
mimetypes.rdf.

Regards,

Dave McKenna



0
David
2/13/2011 4:10:43 PM
On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:

> 
> New betas of Firefox and Seamonkey are now available.  They feature
> the latest Mozilla code plus small refinements to the OS/2 features
> seen in previous betas.
> 
> * Firefox v4.0b12pre:
>     ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>   or
>     http://e-vertise.com/warpzilla/firefox-20110210.zip
>  
> * Seamonkey v2.1b3pre:
>     ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>   or
>     http://e-vertise.com/warpzilla/seamonkey-20110210.zip
....

This version seems a lot more stable then the previous one, however, speed wise 
I'm guessing it's a tad slower then the 20101030 drop (which by far has been the
most stable and speediest on my system).

In addition to the above a few times now I've noticed something really peculiar.
First time Friefox comes up and I go to a site the 'rendering' icon freezes for 
quite some time...browser appers to be locked up for that period, eventually 
(anywhere between 10-30 sec) the browser comes back from the 'la la land'....and
all is good.

I have not seen this behaviour in any other drops...so I'm keeping an eye on 
this. I did recently upgrade to new SMP hardware...so maybe this is complicating
things? Same SMP hardware does run the 20101030 drop very reliably though.
0
Dariusz
2/13/2011 4:12:49 PM
Dave Saville wrote:
> I have just spent some time with Only FF running and only using one
> tab.
>
> I downloaded one of the ebooks to local (JFS) drive.
> Test sequence is:
>
> Display home page.
> Clear cache
> load ebook.
> Repeat
>
> In general without DIVE tends to give longer times.
>
> DIVE: Shortest 12secs, Longest 2 minutes 30 secs
> NoDIVE: Shortest 11secs, Longest 4 minutes

Have you tried with a new profile?
You might also want to test SeaMonkey.
Dave
0
Dave
2/13/2011 5:19:32 PM
> ...totally forgot to mention that the printer is obviously Postscript capable,
> using 30.792 driver...

30.792 ? Where did you get that from ? I am using 30.622 (german) as the latest driver version (30.827) would always hang
my system (but that is a known problem as far as I know).

Lars

0
Lars
2/13/2011 5:54:29 PM
Lars Erdmann wrote:
>> ...totally forgot to mention that the printer is obviously Postscript capable,
>> using 30.792 driver...
>
> 30.792 ? Where did you get that from ? I am using 30.622 (german) as the latest driver version (30.827) would always hang
> my system (but that is a known problem as far as I know).
>
> Lars
>
Correction: 30.822 (german) that is. I wonder if that is really newer than what you are using.
The version numbering seems to be not necessarily consistent across the various languages.

Lars
0
Lars
2/13/2011 5:58:52 PM
On Sun, 13 Feb 2011 17:19:32 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

> Dave Saville wrote:
> > I have just spent some time with Only FF running and only using one
> > tab.
> >
> > I downloaded one of the ebooks to local (JFS) drive.
> > Test sequence is:
> >
> > Display home page.
> > Clear cache
> > load ebook.
> > Repeat
> >
> > In general without DIVE tends to give longer times.
> >
> > DIVE: Shortest 12secs, Longest 2 minutes 30 secs
> > NoDIVE: Shortest 11secs, Longest 4 minutes
> 
> Have you tried with a new profile?

Not yet.

> You might also want to test SeaMonkey.
> Dave
Is that not sort of orphaned?  Not sure of relationship to FF. ISTR it
is the old combined browser/mailer?

-- 
Regards
Dave Saville
0
Dave
2/13/2011 7:16:59 PM
On Sun, 13 Feb 2011 17:54:29 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> > ...totally forgot to mention that the printer is obviously Postscript capable,
> > using 30.792 driver...
> 
> 30.792 ? Where did you get that from ? I am using 30.622 (german) as the latest driver version (30.827) would always hang
> my system (but that is a known problem as far as I know).
> 
> Lars

You know what...it's been a while, and I can't honestly remember...but I must 
have downloaded this off of one of the IBM support sites way back when.

Here are the appropriate contents:

[G:\os2\dll\pscript]dir

The volume label in drive G is OS2_NEW.
The Volume Serial Number is 7E5B:D002.
Directory of G:\os2\dll\pscript

 2-28-10   1:45a     <DIR>           0  .
 2-13-11  12:46a     <DIR>           0  ..
 5-29-03   2:35p    807934       16728  -u
 6-29-03  10:27p      4799           0  auxprint.pak
 5-29-03   2:23p    141434          61  pin.exe
 5-29-03   2:23p     10132           0  pin.sym
 5-29-03   2:23p     58223          61  ppdenc.exe
 5-29-03   2:23p      5236           0  ppdenc.sym
 5-29-03   2:24p   3431922           0  printer1.pak
 5-29-03   2:35p    807934       16728  pscript.drv
 5-29-03   2:35p    807934       16728  pscript.drv.original
 5-29-03   2:24p     49169           0  pscript.hlp
 5-29-03   2:24p     37876           0  pscript.sym
       13 file(s)    6162593 bytes used
                   5475317 K bytes free

[G:\os2\dll\pscript]bldlevel pscript.drv
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:30.792#@ PSCRIPT PRINTER DEVICE DRIVER DYNA-LINK
Vendor:          IBM
Revision:        30.792
File Version:    30.792
Description:     PSCRIPT PRINTER DEVICE DRIVER DYNA-LINK

I do remember that I have applied my Brother printer PPD to the default IBM 
driver.

-Dariusz
0
Dariusz
2/13/2011 7:44:26 PM
Dave Saville wrote:

>> You might also want to test SeaMonkey.
>
> Is that not sort of orphaned?  Not sure of relationship to FF. ISTR it
> is the old combined browser/mailer?

Orphaned by the Mozilla Foundation, but Thunderbird practically is as 
well.  Seamonkey continues to be as current as Firefox.
0
Steve
2/13/2011 7:56:08 PM
Dave Saville wrote:
>> >  Have you tried with a new profile?
> Not yet.
>
>> >  You might also want to test SeaMonkey.
>> >  Dave
> Is that not sort of orphaned?  Not sure of relationship to FF. ISTR it
> is the old combined browser/mailer?

It is sort of orphaned in the sense that Mozilla doesn't officially 
support it. Mozilla does give it a lot of resources and SeaMonkey uses 
exactly the same rendering etc as Firefox. EG the user agent string 
includes Firefox, Mozilla/5.0 (OS/2; Warp 4.5; rv:2.0b11) Gecko/20110205 
Firefox/4.0b11 SeaMonkey/2.1b2pre
Give it a try
Dave
0
Dave
2/13/2011 7:59:58 PM
On Sun, 13 Feb 2011 16:03:33 UTC, "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net> wrote:
> On Sat, 12 Feb 2011 03:23:43 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:
> 
> > So far, no one has explicitly told me whether it works or not.
> > Could people who've successfully used the 'built-in' option try
> > [print.os2.postscript.use_ibmnull "false"] and report whether it:
> > a) breaks printing
> > b) prints but doesn't use the options you've set
> > c) prints and uses the driver's option (e.g. duplexing)
> 
> Here are the tests I ran...hopefully this answers your question above...my 
> printer is a Brother HL-1650 (networked through a built-in NIC print server), 
> printer has 128MB cache and I am printing to it through SLPR port using 
> 'LPRPROTD Compatible' mode:
> 
> RUN  built-in  ibmnull  DPI  DUPLEX  SIZE   RESULT
> 1    FALSE     FALSE    300  YES     3843K  low quality, takes long, duplex OK.
> 2    FALSE     FALSE    600  YES    12217K  quality OK, takes longer, duplex OK.
> 3    FALSE     TRUE     600  YES    12217K  quality same as #3, takes longer, duplex OK.
> 4    TRUE      TRUE     600  YES      625k  best quality, fairly quick, no duplex.
> 5    TRUE      FALSE    600  YES      625K  slightly worse quality then #4,
>                                             but better then #3, duplex OK.
> 6    TRUE      FALSE   1200  YES      625K  best quality, same as #4, fairly quick,
>                                             duplex OK.
> 
> Overall, #5 & 6 settings are by far producing the best combination of output 
> quality and printer feature support. The fact that I am getting DUPLEX print 
> output is what I am particularly happy about. Prints #1 through #3 took 
> extremely long though...obviously these spool files are larger, but 
> still...compared to some other print jobs these ones took 'forever'...LOL.
> 
> The only strange thing is that whereas #5 job was @ 600 DPI and it's SPOOL size 
> was 625K, #6 was a 1200 DPI job but it's spool size was also 625K...however the 
> real output of #6 is noticeably better, and it certainly is the 1200 DPI that I 
> would normally get out of the printer for other non-Firefox print jobs.

Thanks for the info. It's good to hear that _something_ works right.

For runs 1-3, Moz is feeding a giant bitmap to the to your PS driver.  There's
very little Postscript there and it shows.  However, the driver passes along
all of your options to the printer.  The setting for ibmnull isn't used at all.

For runs 4-6, Moz is creating the PS.  For #4, ibmnull is sending the output,
completely unchanged, to the printer.  None of the options you set in the PS
driver are used (including DPI), so the printer is using its default settings.
For 5 and 6, the PS driver is sending commands corresponding to its various
options to the printer, then Moz's PS output (again, unchanged).  Happily,
your printer is responding to those commands (honestly, I doubted it would).

So, when use_builtin is true, the job size will vary depending on the DPI.
When it's false, the file that ends up in your spool directory won't vary
because it only contains Postscript commands that aren't affected by DPI
settings.

The actual number of bytes sent to the printer will be slightly larger if
use_ibmnull is false because the PS driver will send your options before
it copies the file to the printer.  To see what it's adding, check "Output
to file" on the Output Port page of that printer's notebook.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
2/14/2011 2:44:37 AM
On Sun, 13 Feb 2011 09:20:01 UTC, "Dave Saville" <dave@invalid.invalid> wrote:

> I downloaded one of the ebooks to local (JFS) drive. Test sequence is:
> 
> Display home page. 
> Clear cache
> load ebook.
> Repeat
> 
> In general without DIVE tends to give longer times.
> 
> DIVE: Shortest 12secs, Longest 2 minutes 30 secs
> NoDIVE: Shortest 11secs, Longest 4 minutes
[snip]
> 
> The only advantage I can see of turning DIVE off is the black hole 
> under the mouse seems not to occur.

DIVE is only used to move the visible portion of the page to the screen.
It should have no effect on how long it takes Moz to composite the page.

However, if you perceive some benefit try this:  SET MOZ_ACCELERATED=1

This enables DIVE but forces it to hide the pointer whenever the
screen is being updated, and to redraw it when the update is done.
This bypasses the detection code which may be getting things wrong
or even causing the black hole problem.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
2/14/2011 2:53:40 AM
On Mon, 14 Feb 2011 02:53:40 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> DIVE is only used to move the visible portion of the page to the screen.
> It should have no effect on how long it takes Moz to composite the page.
> 
> However, if you perceive some benefit try this:  SET MOZ_ACCELERATED=1

Will try that. Thanks. At the moment it is enabled by default and 
ff.log shows:

[T:\tmp]cat ff.log
en/ex os2Printers
VMI_CMD_SETPTR - rc= 0  ulStatus= 1
Video driver is SNAP - mouse ptr will not be hidden
_init_dive:  hDive= 1  scrn= 0x4950000  format= BGR4
DIVE has been enabled

However I have solved the hang problem - it is Adblock+. Disable it 
and I can clear cache/reload time and time again with an average of 10
seconds. Turn it on and performance goes out the window. The page I am
testing with has only six external hrefs, to the same place, and 30 
internal to the page plus 6 img tags which are also local. Hardly 
anything.

I tried a complete clean and reinstall of ABP. Reload times 10 sec. 
Added the Easylist subscription - times out the window again.

-- 
Regards
Dave Saville
0
Dave
2/14/2011 11:54:28 AM
On Sat, 12 Feb 2011 07:32:14 UTC, Steve Wendt <spamsux@forgetit.org> 
wrote:

> Dave Yeo wrote:
> 
> >>>> This build seems to stop doing the urlbar autocompletion after it has
> >>>> been open for a little while. Anyone else see that?
> >
> > It also seemed to be related to the number of tabs open. Lots of open
> > tabs then if I opened a blank one it seemed to start.
> 
> No tabs open when I've seen it here, just the single window.  I'm sure I 
> had a few tabs open before that, though (but not very many at once, 
> maybe 3 or 4).

Ya'll jinxed me :P  I had not seen this issue in prior builds but 
after reading this, now it seems to the norm.
Andy
-- 

0
Andy
2/14/2011 3:28:12 PM
On Mon, 14 Feb 2011 02:53:40 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

<snip>

> However, if you perceive some benefit try this:  SET MOZ_ACCELERATED=1
> 
> This enables DIVE but forces it to hide the pointer whenever the
> screen is being updated, and to redraw it when the update is done.
> This bypasses the detection code which may be getting things wrong
> or even causing the black hole problem.

Seems to have fixed it at the expense of sometimes causing the mouse 
to flicker. 

[T:\tmp]cat ff.log
en/ex os2Printers
DIVE forced on by MOZ_ACCELERATED=1  - pointer will be hidden
_init_dive:  hDive= 1  scrn= 0x4950000  format= BGR4
DIVE has been enabled


-- 
Regards
Dave Saville
0
Dave
2/14/2011 5:35:01 PM
On Mon, 14 Feb 2011 11:54:28 UTC, "Dave Saville" 
<dave@invalid.invalid> wrote:

> Added the Easylist subscription - times out the window again.

That probably explains the problem. How many entries does that add?

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

0
Doug
2/14/2011 8:20:09 PM
On Mon, 14 Feb 2011 20:20:09 UTC, "Doug Bissett" 
<dougb007!SPAM@telus.net> wrote:

> On Mon, 14 Feb 2011 11:54:28 UTC, "Dave Saville" 
> <dave@invalid.invalid> wrote:
> 
> > Added the Easylist subscription - times out the window again.
> 
> That probably explains the problem. How many entries does that add?
> 

No idea - but it is a lot. However, I fail to see *why* it is doing 
whatever it is doing. As I said the page in question only has 35 
href's and most of them are internal to the page. Something odd is 
going on I feel. Have opened a thread on the ABP forum - see if 
anything comes out of that.
-- 
Regards
Dave Saville
0
Dave
2/14/2011 8:38:08 PM
Dave Saville wrote:

>> This enables DIVE but forces it to hide the pointer whenever the
>> screen is being updated, and to redraw it when the update is done.
>
> Seems to have fixed it at the expense of sometimes causing the mouse
> to flicker.

That's exactly how it works without full hardware cursor support.  It's 
been too long for me to remember, but the VIA Blade 3D may not work too 
well in that regard.
0
Steve
2/14/2011 10:26:26 PM
Andy wrote:

>>>>>> This build seems to stop doing the urlbar autocompletion after it has
>>>>>> been open for a little while. Anyone else see that?
>
> Ya'll jinxed me :P  I had not seen this issue in prior builds but
> after reading this, now it seems to the norm.

It wasn't in prior builds, as far as I know.  It seems to be a bug in 
places, as a related symptom is that visited links no longer show the 
visited link color.

Whether it is cross-platform or not, I have no idea.  Perhaps someone 
will be kind enough to generate builds that correspond to actual 
releases (Seamonkey 2.1 beta 2 and Firefox 4.0 beta 12); that always 
makes it a lot easier to test for cross-platform issues, and minimizes 
the amount of random nightly bugs.
0
Steve
2/14/2011 10:31:41 PM
On Mon, 14 Feb 2011 20:38:08 UTC, "Dave Saville" 
<dave@invalid.invalid> wrote:

> On Mon, 14 Feb 2011 20:20:09 UTC, "Doug Bissett" 
> <dougb007!SPAM@telus.net> wrote:
> 
> > On Mon, 14 Feb 2011 11:54:28 UTC, "Dave Saville" 
> > <dave@invalid.invalid> wrote:
> > 
> > > Added the Easylist subscription - times out the window again.
> > 
> > That probably explains the problem. How many entries does that add?
> > 
> 
> No idea - but it is a lot. However, I fail to see *why* it is doing 
> whatever it is doing. As I said the page in question only has 35 
> href's and most of them are internal to the page. Something odd is 
> going on I feel. Have opened a thread on the ABP forum - see if 
> anything comes out of that.

I never tried the Easylist option, prefering to build my own list as I
went along. Apparently, that was a good idea. My list is less than 
2000 characters, with less than 100 lines. 

Chances are that ABP is scanning the whole list for every href. If 
that happens to cause the file contents to overflow the disk cache, it
would need to read all, or most, of the file again, for each scan, 
which would definitely slow things down. That is one of the main 
reasons why PMMail recommends using a JFS volume, so that the 
bogofilter database won't cause the cache overflow problem. Of course,
you could also get into the "thrashing" problem with the OS/2 swap 
file if you don't have sufficient memory, and/or if you don't have 
enough space allocated to the swap file, but that is probably not what
this problem is.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

0
Doug
2/14/2011 10:52:47 PM
Steve Wendt wrote:
> Andy wrote:
>
>>>>>>> This build seems to stop doing the urlbar autocompletion after it
>>>>>>> has
>>>>>>> been open for a little while. Anyone else see that?
>>
>> Ya'll jinxed me :P I had not seen this issue in prior builds but
>> after reading this, now it seems to the norm.
>
> It wasn't in prior builds, as far as I know. It seems to be a bug in
> places, as a related symptom is that visited links no longer show the
> visited link color.
>
> Whether it is cross-platform or not, I have no idea. Perhaps someone
> will be kind enough to generate builds that correspond to actual
> releases (Seamonkey 2.1 beta 2 and Firefox 4.0 beta 12); that always
> makes it a lot easier to test for cross-platform issues, and minimizes
> the amount of random nightly bugs.

I'm using what is planned to be 2.b2 (still hasn't been finalized as far 
as I know) and both these problems have cleared up. I saw them for a 
couple of weeks prior to this build.
Dave
0
Dave
2/15/2011 12:08:49 AM
On Mon, 14 Feb 2011 17:35:01 UTC, "Dave Saville" wrote:
> On Mon, 14 Feb 2011 02:53:40 UTC, "Rich Walsh" wrote:
> 
> > However, if you perceive some benefit try this:  SET MOZ_ACCELERATED=1
> > 
> > This enables DIVE but forces it to hide the pointer whenever the
> > screen is being updated, and to redraw it when the update is done.
> > This bypasses the detection code which may be getting things wrong
> > or even causing the black hole problem.
> 
> Seems to have fixed it at the expense of sometimes causing the mouse 
> to flicker. 
> 
> [T:\tmp]cat ff.log
> en/ex os2Printers
> DIVE forced on by MOZ_ACCELERATED=1  - pointer will be hidden
> _init_dive:  hDive= 1  scrn= 0x4950000  format= BGR4
> DIVE has been enabled

If you'd like to be _really_ helpful, you could try this:

  SET MOZ_ACCELERATED=2

Like "SET MOZ_ACCELERATED=1", it forces DIVE on but tells the code
not to hide the pointer.  The point of this test is that it bypasses
the detection code.  I'd like determine whether SNAP is messing up
your mouse pointer on its own or whether the detection code is what's
causing the problem.

Thanks for your help.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
2/15/2011 12:49:20 AM
Dave Yeo wrote:
> Steve Wendt wrote:
>> Andy wrote:
>>
>>>>>>>> This build seems to stop doing the urlbar autocompletion after it
>>>>>>>> has
>>>>>>>> been open for a little while. Anyone else see that?
>>>
>>> Ya'll jinxed me :P I had not seen this issue in prior builds but
>>> after reading this, now it seems to the norm.
>>
>> It wasn't in prior builds, as far as I know. It seems to be a bug in
>> places, as a related symptom is that visited links no longer show the
>> visited link color.
>>
>> Whether it is cross-platform or not, I have no idea. Perhaps someone
>> will be kind enough to generate builds that correspond to actual
>> releases (Seamonkey 2.1 beta 2 and Firefox 4.0 beta 12); that always
>> makes it a lot easier to test for cross-platform issues, and minimizes
>> the amount of random nightly bugs.
>
> I'm using what is planned to be 2.b2 (still hasn't been finalized as far
> as I know) and both these problems have cleared up. I saw them for a
> couple of weeks prior to this build.
> Dave

Of course now it appears :) Took quite a while.
Dave
0
Dave
2/15/2011 5:06:11 AM
Dave Yeo wrote:
> Dave Yeo wrote:
>> Steve Wendt wrote:
>>> Andy wrote:
>>>
>>>>>>>>> This build seems to stop doing the urlbar autocompletion after it
>>>>>>>>> has
>>>>>>>>> been open for a little while. Anyone else see that?
>>>>
>>>> Ya'll jinxed me :P I had not seen this issue in prior builds but
>>>> after reading this, now it seems to the norm.
>>>
>>> It wasn't in prior builds, as far as I know. It seems to be a bug in
>>> places, as a related symptom is that visited links no longer show the
>>> visited link color.
>>>
>>> Whether it is cross-platform or not, I have no idea. Perhaps someone
>>> will be kind enough to generate builds that correspond to actual
>>> releases (Seamonkey 2.1 beta 2 and Firefox 4.0 beta 12); that always
>>> makes it a lot easier to test for cross-platform issues, and minimizes
>>> the amount of random nightly bugs.
>>
>> I'm using what is planned to be 2.b2 (still hasn't been finalized as far
>> as I know) and both these problems have cleared up. I saw them for a
>> couple of weeks prior to this build.
>> Dave
>
> Of course now it appears :) Took quite a while.

Should note that this showed up after a sys3071 in SeaMonkey and cleared 
up after a restart. A similar bug is #629125.
Dave
0
Dave
2/15/2011 6:08:49 AM
On 02/14/11 04:08 pm, Dave Yeo wrote:
> I'm using what is planned to be 2.b2 (still hasn't been finalized as far
> as I know)

And 2.1b2 is out.
Dave
0
Dave
2/15/2011 6:17:26 AM
Dave Yeo wrote:

>> I'm using what is planned to be 2.b2 (still hasn't been finalized as far
>> as I know)
>
> And 2.1b2 is out.

Now including the meaning of life, the universe, and everything 
(about:life).
0
Steve
2/15/2011 7:48:37 AM
On 02/14/11 11:48 pm, Steve Wendt wrote:
> Dave Yeo wrote:
>
>>> I'm using what is planned to be 2.b2 (still hasn't been finalized as far
>>> as I know)
>>
>> And 2.1b2 is out.
>
> Now including the meaning of life, the universe, and everything
> (about:life).

At least they got it right :)
Dave

0
Dave
2/15/2011 8:20:40 AM
On Tue, 15 Feb 2011 00:49:20 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> If you'd like to be _really_ helpful, you could try this:
> 
>   SET MOZ_ACCELERATED=2
> 
> Like "SET MOZ_ACCELERATED=1", it forces DIVE on but tells the code
> not to hide the pointer.  The point of this test is that it bypasses
> the detection code.  I'd like determine whether SNAP is messing up
> your mouse pointer on its own or whether the detection code is what's
> causing the problem.

[T:\tmp]cat ff.log
en/ex os2Printers
DIVE forced on by MOZ_ACCELERATED=2  - pointer will not be hidden
_init_dive:  hDive= 1  scrn= 0x4950000  format= BGR4
DIVE has been enabled

Black hole back. :-(

And if you would like to be _really_ helpful :-)

Any chance of stopping FF writing what it thinks is in the clipboard 
*to* the clipboard when it shuts down? If the contents happen to be a 
URL and ClipView is set to open them .... it promptly retsarts FF. 
There is absolutely no reason to write to the clipboard on shutdown. 
And if FF and the clipboard are out of step, which can happen, 
suddenly the clipboard does not have what you thought it had.
-- 
Regards
Dave Saville
0
Dave
2/15/2011 8:45:08 AM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dave Saville
<dave@invalid.invalid>], who wrote in article <fV45K0OBJxbE-pn2-2TsdxbvQmEpZ@localhost>:
> And if you would like to be _really_ helpful :-)
> 
> Any chance of stopping FF writing what it thinks is in the clipboard 
> *to* the clipboard when it shuts down?

We discussed this already, have not we?  What FF does is a correct
behaviour IF it renders different formats on when-needed basis.

> If the contents happen to be a 
> URL and ClipView is set to open them .... it promptly retsarts FF. 

Tough luck...  (Does a new copy/tab opens each time you "Copy link
location"?  Then your setup is buggy anyway...)

> There is absolutely no reason to write to the clipboard on shutdown. 

Wrong.

If something short like an URL is copied to the clipboard, one could
detect this, and render all the formats immediately, AND mark
RENDERALL as not needed.  But this is a lot of extra logic with very
limited benefit...

> And if FF and the clipboard are out of step, which can happen, 

If THIS may happen, THEN there is a bug there.

> suddenly the clipboard does not have what you thought it had.

With correct design, this should not happen indeed.  RENDERALL message
should not be delivered in this situation...

However, as I said earlier, there may be a small optimization which
may (or may not - only testing would show) help you: when a particular
clipboard format is rendered, make FF remember this fact, and do not
rerender this format on exit...

Ilya
0
Ilya
2/15/2011 7:17:23 PM
On Tue, 15 Feb 2011 19:17:23 UTC,  Ilya Zakharevich 
<nospam-abuse@ilyaz.org> wrote:

> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Dave Saville
> <dave@invalid.invalid>], who wrote in article <fV45K0OBJxbE-pn2-2TsdxbvQmEpZ@localhost>:
> > And if you would like to be _really_ helpful :-)
> > 
> > Any chance of stopping FF writing what it thinks is in the clipboard 
> > *to* the clipboard when it shuts down?
> 
> We discussed this already, have not we?  What FF does is a correct
> behaviour IF it renders different formats on when-needed basis.
> 

No you mention it, I think we did - and I did not agree with you last 
time :-)

> > If the contents happen to be a 
> > URL and ClipView is set to open them .... it promptly retsarts FF. 
> 
> Tough luck...  (Does a new copy/tab opens each time you "Copy link
> location"?  Then your setup is buggy anyway...)

If I have it on auto yes, That's what I want. However, I rarely use 
"Copy link location" The code was for the many documents, on the web 
and in email, that *don't* make the URL a clickable link.

> 
> > There is absolutely no reason to write to the clipboard on shutdown. 
> 
> Wrong.
> 

I don't see why. If FF *is* keeping multiple formats and sending 
whatever on demand, and we have no evidence that it does, I still 
don't see why it should decide to write *one* of them out to the 
clipboard on shutdown. Which it does every time.

> If something short like an URL is copied to the clipboard, one could
> detect this, and render all the formats immediately, AND mark
> RENDERALL as not needed.  But this is a lot of extra logic with very
> limited benefit...
> 
> > And if FF and the clipboard are out of step, which can happen, 
> 
> If THIS may happen, THEN there is a bug there.
> 

Seen it many times from very early versions of Firefox right up to 
now. It may of course be tied up with the focus problems FF gets in 
conjunction with Xcenter sliding focus. Which affects *no* other app I
have ever used. So I doubt it is Xcenter.

> > suddenly the clipboard does not have what you thought it had.
> 
> With correct design, this should not happen indeed.  RENDERALL message
> should not be delivered in this situation...
> 

Assuming it is sent. Do we know that for sure?


-- 
Regards
Dave Saville
0
Dave
2/15/2011 7:43:26 PM
Hi All

Peter Brown wrote:
>


----- snip -----


>
> On a slightly different note: I have several Profiles in my
> Desktop\Internet\Seamonkey folder. When the folder is open on the
> Desktop all Profiles and the Seamonkey program object have the icons
> displayed correctly but when I view this folder by clicking the eCS
> "button" on the eComCenter and working through Internet -> Seamonkey the
> list shows mucked up icons for all Profiles with the exception of
> losepete (this Profile) and the Seamonkey object whose icons display
> correctly. Any ideas on the cause of this?
>


Correction: All the above Seamonkey icons now mucked up.

Anyone else seeing this?

Regards

Pete


>
> Regards
>
> Pete
>
>
0
Peter
2/16/2011 12:41:24 AM
On Tue, 15 Feb 2011 08:45:08 UTC, "Dave Saville" <dave@invalid.invalid> wrote:

> Any chance of stopping FF writing what it thinks is in the clipboard 
> *to* the clipboard when it shuts down?

Yes.  This has always struck me as annoying - and pointless on a platform
that has only one clipboard.  Barring any *really* strong (and valid)
objections, consider it done.

BTW, Ilya...  the mozapps don't do any sort of delayed rendering of data
to the clipboard.  As soon as you tell them to copy, they dump everything
onto the clipboard immediately.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
2/16/2011 2:55:10 AM
On Wed, 16 Feb 2011 02:55:10 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Tue, 15 Feb 2011 08:45:08 UTC, "Dave Saville" <dave@invalid.invalid> wrote:
> 
> > Any chance of stopping FF writing what it thinks is in the clipboard 
> > *to* the clipboard when it shuts down?
> 
> Yes.  This has always struck me as annoying - and pointless on a platform
> that has only one clipboard.  Barring any *really* strong (and valid)
> objections, consider it done.
> 
> BTW, Ilya...  the mozapps don't do any sort of delayed rendering of data
> to the clipboard.  As soon as you tell them to copy, they dump everything
> onto the clipboard immediately.
> 

Thank you Rich.

As you can see I am happy to try things out. Have you any ideas on how
we might figure out what FF does not like about Xcenter sliding focus?
In my experience it is the only app that does have a problem. Which 
would point to it being FF rather than Xcenter IMHO.

-- 
Regards
Dave Saville
0
Dave
2/16/2011 3:55:25 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dave Saville
<dave@invalid.invalid>], who wrote in article <fV45K0OBJxbE-pn2-nflcBdqEw6Wd@localhost>:
> > > If the contents happen to be a 
> > > URL and ClipView is set to open them .... it promptly retsarts FF. 
> > 
> > Tough luck...  (Does a new copy/tab opens each time you "Copy link
> > location"?  Then your setup is buggy anyway...)
> 
> If I have it on auto yes, That's what I want. However, I rarely use 
> "Copy link location" The code was for the many documents, on the web 
> and in email, that *don't* make the URL a clickable link.

There should be better solutions for this (although the extension I
have installed is useless - looks like the test for "looks like URL is
inverted" ;-] :-( ).

> I don't see why. If FF *is* keeping multiple formats and sending 
> whatever on demand, and we have no evidence that it does, I still 
> don't see why it should decide to write *one* of them out to the 
> clipboard on shutdown. Which it does every time.

We discussed this already, did not we?  If something is advertised as
available, but is actually done when-required TRANSPARENTLY, then when
the actor exits, to preserve the TRANSPARENCY, all the stuff
advertised as available should be made ACTUALLY available.

Of course, the NEED for this is indeed based on some yet-unverified
conjectures...

> > With correct design, this should not happen indeed.  RENDERALL message
> > should not be delivered in this situation...

> Assuming it is sent. Do we know that for sure?

Assuming this is just the occam's razor.  (A reasonable assumption, and
nothing more...)

Ilya
0
Ilya
2/17/2011 9:24:03 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Rich Walsh
<spamyourself@127.0.0.1>], who wrote in article <brddYgxvE0gm-pn2-PW473e5xhdy3@localhost>:

> BTW, Ilya...  the mozapps don't do any sort of delayed rendering of data
> to the clipboard.  As soon as you tell them to copy, they dump everything
> onto the clipboard immediately.

OK, then if my other suggestion holds (RENDERALL is processed) it
should be easy to find and disable.  I see these

#define WM_RENDERFMT			0x0060
#define WM_RENDERALLFMTS		0x0061
#define WM_DESTROYCLIPBOARD		0x0062
#define WM_PAINTCLIPBOARD		0x0063
#define WM_SIZECLIPBOARD		0x0064
#define WM_HSCROLLCLIPBOARD		0x0065
#define WM_VSCROLLCLIPBOARD		0x0066
#define WM_DRAWCLIPBOARD		0x0067

I assume only the first two are relevant to the problem in question.

Thanks,
Ilya
0
Ilya
2/17/2011 9:30:48 PM
On 02/11/11 10:24 pm, I wrote:

>> New betas of Firefox and Seamonkey are now available. They feature
>> the latest Mozilla code plus small refinements to the OS/2 features
>> seen in previous betas.
>>
>> * Firefox v4.0b12pre:
>> ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110210.zip
>> or
>> http://e-vertise.com/warpzilla/firefox-20110210.zip

> The new FF worked the first few times I tried it, but now I get a couple
> of beeps, the mouse pointer disappears (although if I move the invisible
> pointer up to the top of the screen the eCenter pops up), and FF does
> not start.
>
> How do I remedy this? Start with a new profile, or ...?

I don't know what changed, but now it seems to be working OK.

-=-
Alan
0
Alan
2/22/2011 10:59:50 PM
On 2011/02/11 00:23 (GMT-0600) Rich Walsh composed:

> * Seamonkey v2.1b3pre:
>     ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110210.zip
>   or
>     http://e-vertise.com/warpzilla/seamonkey-20110210.zip

Minimum tab width (92px; modern theme) is now much too wide. Anyone know which
jar contains whatever sets this minimum. I expected CSS, either in main or
theme, but I've had no luck so far finding whatever it is that sets it with
Domi, only the computed width. :-(

I made a userChrome.css rule that works (.tabbrowser-tab {min-width: 3em
!important}), but it's annoying to not be able to get Domi to show me exactly
what it's overriding.
-- 
"How much better to get wisdom than gold, to choose
understanding rather than silver." Proverbs 16:16 NKJV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
2/24/2011 7:48:55 AM
Felix Miata wrote:

>Minimum tab width (92px; modern theme) is now much too wide. Anyone know which jar contains whatever sets this minimum. I expected CSS, either in main or theme, but I've had no luck so far finding whatever it is that sets it with Domi, only the computed width.
>
/browser.tabs.tabM..Width/ in about:config

-- 
Warning: May contain traces of nuts.
0
Neil
2/24/2011 9:54:25 AM
On 2011/02/24 09:54 (GMT) Neil composed:

> Felix Miata wrote:

>> Minimum tab width (92px; modern theme) is now much too wide. Anyone know which jar contains whatever sets this minimum. I expected CSS, either in main or theme, but I've had no luck so far finding whatever it is that sets it with Domi, only the computed width.

> /browser.tabs.tabM..Width/ in about:config


Thanks. Good to know. Still, since I have to have userChrome.css in all
profiles anyway to lose toolbargrippy, userChrome.css seems the better route,
since an em width will preserve the relationship to menu font size regardless
of the DPI that profile is subject to. Or is that pref allowed an alternative
to integer?

P.S. What is tabClipWidth for?
-- 
"How much better to get wisdom than gold, to choose
understanding rather than silver." Proverbs 16:16 NKJV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
2/25/2011 6:01:08 AM
Felix Miata wrote:

>P.S. What is tabClipWidth for?
>  
>
Used in tabmail to decide whether to allow close buttons to appear on 
all tabs (browser.tabs.closeButtons == 1). Not ported to navigator yet.

-- 
Warning: May contain traces of nuts.
0
Neil
2/25/2011 9:42:38 AM
Friday, February 25, 2011

First, thanks for this build.  It has proven stable enough that I can 
use it as my first start browser on eCS2.  My comments on this build:

==========
Extensions
==========

With this build I made a concentrated effort to test my extensions. 
Four of them are work day critical Maff, and three Bible toolbars (two 
of which I maintain).  Once I determined that they worked with the beta, 
I started testing my other favourite addons one by one.  Those which did 
not have FF4 versions, I edited the install.rdfs to make them work.

I was able to test them one by one by manually copying from my FF3 
profile.  The ones which did not work, I simply deleted from the FF4 
profile.


========
Printing
========

Because I want to be able to copy and paste the text in PDFs created 
using ePDF and GS, I am using the eCS native printing.  The beta default 
works fine if printing to a printer, but the PS generated is a graphic.

To avoid having the beta crash when I am printing, I have turned off the 
option to allow pages to pick their own font.  I suspect this is due to 
one or more of the fonts which I am using on my system, because it is 
also required for creation of PDFs with FF3.x.

Phil
0
Philip
2/25/2011 5:17:35 PM
On Fri, 25 Feb 2011 17:17:35 UTC, Philip Griffin-Allwood <grifwood@glinx.com> wrote:

> Because I want to be able to copy and paste the text in PDFs created 
> using ePDF and GS, I am using the eCS native printing.  The beta default 
> works fine if printing to a printer, but the PS generated is a graphic.

If you check "Print to file", then give the filename a .pdf extension.
FF will use its built-in PDF generator to create a "real" PDF file.

Currently, the native PS driver should only be used if your printer
or conversion utility can't handle the output from Moz's built-in
PS generator.  The built-in facility provides better print quality
and much smaller files.  Further, if you tell it not to use IBMNULL
when sending output to the printer, you may be able to use some of
your printer's features that aren't otherwise supported.

The prefs you'd set in "about:config" are:

  print.os2.postscript.use_builtin  true
  print.os2.postscript.use_ibmnull  false

BTW... I'm pretty sure that while driver settings like duplexing
will be used, orientation (landscape/portrait) will not,


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
2/26/2011 1:44:17 AM
Friday 25 February 2011

> If you check "Print to file", then give the filename a .pdf extension.
> FF will use its built-in PDF generator to create a "real" PDF file.

I am aware of this, but was not impressed with the quality of the PDF.

> The built-in facility provides better print quality
> and much smaller files.

I generate PDF files for storge.  My real world test tonight gave me a 
file size of 55,238k using ePDF while the builtin generator size was 
190,378k.  My PDFs are generated with /Printer setting by default.

> The prefs you'd set in "about:config" are:
> 
>   print.os2.postscript.use_builtin  true

This is my current setting.

>   print.os2.postscript.use_ibmnull  false

I had this set to true and will try it set to false.

> BTW... I'm pretty sure that while driver settings like duplexing
> will be used, orientation (landscape/portrait) will not,

Since I only use the Ghostscript PDF driver for printing in Portrait, I 
had not realized the other ffeatures were missing.

Phil
0
Philip
2/26/2011 2:35:05 AM
On Sat, 26 Feb 2011 02:35:05 UTC, Philip Griffin-Allwood <grifwood@glinx.com> wrote:

>> The prefs you'd set in "about:config" are:
>> 
>>   print.os2.postscript.use_builtin  true
> 
> This is my current setting.

Hmmm....  I'm confused.  Previously, you said

>>> Because I want to be able to copy and paste the text in PDFs created 
>>> using ePDF and GS, I am using the eCS native printing.  The beta default 
>>> works fine if printing to a printer, but the PS generated is a graphic.

"eCS native printing" is the default and does indeed create a big graphic,
but to get it you'd have to set the above option to 'false'.  When set to
'true' (especially with print.os2.postscript.use_ibmnull also set to 'true'),
there virtually nothing "native" about the process.  All PM does is copy a
ready-made PS file to a printer without changing its contents.

Regardless of terminology, if it's doing what you need, great.  If not,
perhaps there's an arrangement that would suit you better.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
2/27/2011 6:32:01 AM
On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh" <spamyourself@127.0.0.1> 
wrote:

Problem URL, repeatable here:
http://fixunix.com/os2/42922-synchronize-utility.html

firefox-20101204.zip:
Posts' text displays OK

firefox-20110210.zip
Posts' text are blank/transparent.  Marking the text for copying shows 
that there is *something* there, but no characters are displayed.

Matrox G550, I think.
SNAP last Enterprise version.
W4 FP17

-- 
Regards,
Al S.
0
Al
2/27/2011 7:04:58 PM
Al Savage wrote:
> On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh"<spamyourself@127.0.0.1>
> wrote:
>
> Problem URL, repeatable here:
> http://fixunix.com/os2/42922-synchronize-utility.html
>
> firefox-20101204.zip:
> Posts' text displays OK
>
> firefox-20110210.zip
> Posts' text are blank/transparent.  Marking the text for copying shows
> that there is *something* there, but no characters are displayed.
>

Works fine here with firefox-20110219 so probably just a transient 
problem in the daily build.
You did make me curious about the SD22 compression guage as I looked 
around quite a bit for one for my old SD25 (now recycled). Loved that 
engine.
Dave

0
Dave
2/27/2011 7:45:45 PM
On Sun, 27 Feb 2011 19:45:45 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

> Al Savage wrote:
> > On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh"<spamyourself@127.0.0.1>
> > wrote:
> >
> > Problem URL, repeatable here:
> > http://fixunix.com/os2/42922-synchronize-utility.html
> >
> > firefox-20101204.zip:
> > Posts' text displays OK
> >
> > firefox-20110210.zip
> > Posts' text are blank/transparent.  Marking the text for copying shows
> > that there is *something* there, but no characters are displayed.
> >
> 
> Works fine here with firefox-20110219 so probably just a transient 
> problem in the daily build.
> You did make me curious about the SD22 compression guage as I looked 
> around quite a bit for one for my old SD25 (now recycled). Loved that 
> engine.
> Dave
> 

Same build as Al and I have been playing with the html and can't get 
it to print unless I make the text strong.

BTW to anser your question Al - Easysync on Hobbes.

-- 
Regards
Dave Saville
0
Dave
2/27/2011 8:13:27 PM
On Sun, 27 Feb 2011 19:45:45 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

> Al Savage wrote:
> > On Fri, 11 Feb 2011 06:23:01 UTC, "Rich Walsh"<spamyourself@127.0.0.1>
> > wrote:
> >
> > Problem URL, repeatable here:
> > http://fixunix.com/os2/42922-synchronize-utility.html
> >
> > firefox-20101204.zip:
> > Posts' text displays OK
> >
> > firefox-20110210.zip
> > Posts' text are blank/transparent.  Marking the text for copying shows
> > that there is *something* there, but no characters are displayed.
> >
> 
> Works fine here with firefox-20110219 so probably just a transient 
> problem in the daily build.
> You did make me curious about the SD22 compression guage as I looked 
> around quite a bit for one for my old SD25 (now recycled). Loved that 
> engine.
> Dave
> 

It's this css 
<style type="text/css" id="vbulletin_css">

- delete the link to that and the page looks almost OK.

-- 
Regards
Dave Saville
0
Dave
2/27/2011 8:31:30 PM
Dave Saville wrote:

>>> Problem URL, repeatable here:
>>> http://fixunix.com/os2/42922-synchronize-utility.html
>>>
>>> Posts' text are blank/transparent.  Marking the text for copying shows
>>> that there is *something* there, but no characters are displayed.
>
> It's this css
> <style type="text/css" id="vbulletin_css">

It's definitely related to CSS and JS; if you "Use Style -> None" you 
can see all the text.  The error console shows a ton of warnings, but 
the one that stands out the most to me points to this page:

https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing

Odds are that they work around bugs like this in the newer code that 
Dave Yeo mentioned he was running.
0
Steve
2/27/2011 10:13:26 PM
On Sun, 27 Feb 2011 19:45:45 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> You did make me curious about the SD22 compression guage as I looked 
> around quite a bit for one for my old SD25 (now recycled). Loved that 
> engine.

http://nissandiesel.dyndns.org/viewtopic.php?t=52
That's the setup I came up with seven years ago, instead of the Nissan 
injector hole adapter than nobody has available.

I run the NissanDiesel site at http://nissandiesel.dyndns.org and have 
contributed a lot of the useful content over the past several years.  
Here in the States, we only had 720 (pickup) diesels 1981-85 (-87 in 
Canada), Sentra diesels 1983-86, and Maxima diesels 1981-83.  I've owned
one or more of each over the years.  None of the engines are remotely 
like any of the others. CD, LD, SD engines, all completely different for
their tasks.  Nissan has made a *lot* of different diesel engines over 
the decades.

Now, I'm playing with an '86 Toyota Camry turbodiesel, last year 
imported to here.

-- 
Regards,
Al S.
0
Al
2/28/2011 1:27:44 AM
On Sun, 27 Feb 2011 20:13:27 UTC, "Dave Saville" <dave@invalid.invalid> 
wrote:

 
> BTW to anser your question Al - Easysync on Hobbes.

I've resuscitated CopyDir.cmd from 2003 and have it working well again, 
but Thanks. More on that over in c.o.o.apps .

-- 
Regards,
Al S.
0
Al
2/28/2011 1:30:21 AM
Hi All

Peter Brown wrote:
> Hi All
>
> Peter Brown wrote:
>>
>
>
> ----- snip -----
>
>
>>
>> On a slightly different note: I have several Profiles in my
>> Desktop\Internet\Seamonkey folder. When the folder is open on the
>> Desktop all Profiles and the Seamonkey program object have the icons
>> displayed correctly but when I view this folder by clicking the eCS
>> "button" on the eComCenter and working through Internet -> Seamonkey the
>> list shows mucked up icons for all Profiles with the exception of
>> losepete (this Profile) and the Seamonkey object whose icons display
>> correctly. Any ideas on the cause of this?
>>
>
>
> Correction: All the above Seamonkey icons now mucked up.
>
> Anyone else seeing this?
>
> Regards
>
> Pete
>



As no-one else seems to be seeing this icon problem I guess It is 
something that has suddenly gone coincidentally wrong with my system 
when I installed this build of Seamonkey and only affects these 
Seamonkey icons.

Any ideas on a fix?

Regards

Pete

0
Peter
3/1/2011 1:28:55 AM
On Tue, 1 Mar 2011 01:28:55 UTC, Peter Brown <losepeteSPAM-ME-NOT@ntlworld.com> wrote:

> > Correction: All the above Seamonkey icons now mucked up.

Almost all of the seamonkey.exe icons are corrupt.  Only the 40x40x24bit
icon looks like it should.  The top 6 lines of the 32x32x24bit icon are
corrupted, and the 10 other icons are just a jumble of dots.

Since the icons in the original seamonkey.exe file are all OK, I have
to blame lxlite.  We just started using that because we switched to
the OpenWatcom linker and it doesn't compress binaries the way the
IBM linKer does.  (The distro would proably be 40% larger without it.)

I'll play with its settings to see if we can avoid this corruption.
If not, we'll just distribute the uncompressed version (it's only
11k larger).


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
3/2/2011 2:21:14 AM
Rich Walsh wrote:

> Since the icons in the original seamonkey.exe file are all OK, I have
> to blame lxlite.  We just started using that because we switched to
> the OpenWatcom linker and it doesn't compress binaries the way the
> IBM linKer does.  (The distro would proably be 40% larger without it.)
>
> I'll play with its settings to see if we can avoid this corruption.

I have a vague recollection that Peter Weilbacher solved this before.
0
Steve
3/2/2011 4:11:54 AM
Steve Wendt wrote:

>> Since the icons in the original seamonkey.exe file are all OK, I have
>> to blame lxlite. We just started using that because we switched to
>> the OpenWatcom linker and it doesn't compress binaries the way the
>> IBM linKer does. (The distro would proably be 40% larger without it.)
>>
>> I'll play with its settings to see if we can avoid this corruption.
>
> I have a vague recollection that Peter Weilbacher solved this before.

But all I can find right now is this:
http://permalink.gmane.org/gmane.comp.mozilla.devel.os2/28464
0
Steve
3/2/2011 4:21:15 AM
Hi

Steve Wendt wrote:
> Steve Wendt wrote:
>
>>> Since the icons in the original seamonkey.exe file are all OK, I have
>>> to blame lxlite. We just started using that because we switched to
>>> the OpenWatcom linker and it doesn't compress binaries the way the
>>> IBM linKer does. (The distro would proably be 40% larger without it.)
>>>
>>> I'll play with its settings to see if we can avoid this corruption.
>>
>> I have a vague recollection that Peter Weilbacher solved this before.
>
> But all I can find right now is this:
> http://permalink.gmane.org/gmane.comp.mozilla.devel.os2/28464


As I had reported this problem in this ng with a previous Seamonkey 
build I had a search for my post. This is the thread to read:
Several minor moans about Seamonkey2.0a1pre...

A quick reread suggests that Peter Weilbacher solved the problem by not 
using lxlite.

Regards

Pete
0
Peter
3/2/2011 5:29:50 PM
Peter Brown wrote:
> Hi
>
> Steve Wendt wrote:
>> Steve Wendt wrote:
>>
>>>> Since the icons in the original seamonkey.exe file are all OK, I have
>>>> to blame lxlite. We just started using that because we switched to
>>>> the OpenWatcom linker and it doesn't compress binaries the way the
>>>> IBM linKer does. (The distro would proably be 40% larger without it.)
>>>>
>>>> I'll play with its settings to see if we can avoid this corruption.
>>>
>>> I have a vague recollection that Peter Weilbacher solved this before.
>>
>> But all I can find right now is this:
>> http://permalink.gmane.org/gmane.comp.mozilla.devel.os2/28464
>
>
> As I had reported this problem in this ng with a previous Seamonkey
> build I had a search for my post. This is the thread to read:
> Several minor moans about Seamonkey2.0a1pre...
>
> A quick reread suggests that Peter Weilbacher solved the problem by not
> using lxlite.
>

No we were using lxlite before Rich updated the packaging, just a 
simpler command line.
--- a/toolkit/mozapps/installer/os2/strip.cmd
+++ b/toolkit/mozapps/installer/os2/strip.cmd
@@ -1,2 +1,7 @@
  @rem compress binaries for optimum performance without disturbing chkdll32
-lxlite /ydd /yxd /d %1
+
+@rem yes to: abort if in use, delete debug & extra data, leave 
non-resident names;
+@rem align no-bounday/page-shift; no backup; use stdio; discard 
existing exe/dll settings;
+@rem normal priority; packing: LZ, medium run lth, medium fixup; 
recursive search;
+@rem unpack before pack; pack files; leave stub, remove debug & extra data;
+lxlite *.exe *.dll /yua /ydd /yxd /ynl /anp /b- /cs+ /d /i- /ml1 /mr2 
/mf2 /r+ /u+ /x- /zs:0 /zx /zd

Dave

0
Dave
3/2/2011 7:57:04 PM
On Mar 2, 3:21=A0am, "Rich Walsh" <spamyours...@127.0.0.1> wrote:
> On Tue, 1 Mar 2011 01:28:55 UTC, Peter Brown <losepeteSPAM-ME-...@ntlworl=
d.com> wrote:
> > > Correction: All the above Seamonkey icons now mucked up.
>
> Almost all of the seamonkey.exe icons are corrupt. =A0Only the 40x40x24bi=
t
> icon looks like it should. =A0The top 6 lines of the 32x32x24bit icon are
> corrupted, and the 10 other icons are just a jumble of dots.
>
> Since the icons in the original seamonkey.exe file are all OK, I have
> to blame lxlite. =A0

> I'll play with its settings to see if we can avoid this corruption.
> If not, we'll just distribute the uncompressed version (it's only
> 11k larger).
>
> --
> =3D=3D =3D=3D almost usable email address: =A0Rich AT E-vertise DOT Com =
=3D=3D =3D=3D

There was a line in packager.mk that prevented ico and exe files from
being stripped (compressed by lxlite). Probably the distortion of the
icons was the reason for it.
Walter
0
Walter
3/2/2011 9:03:45 PM
On Mar 2, 10:03=A0pm, Walter Meinl <w...@lsvw.de> wrote:
> On Mar 2, 3:21=A0am, "Rich Walsh" <spamyours...@127.0.0.1> wrote:
>
> > On Tue, 1 Mar 2011 01:28:55 UTC, Peter Brown <losepeteSPAM-ME-...@ntlwo=
rld.com> wrote:
> > > > Correction: All the above Seamonkey icons now mucked up.
>
> > Almost all of the seamonkey.exe icons are corrupt. =A0Only the 40x40x24=
bit
> > icon looks like it should. =A0The top 6 lines of the 32x32x24bit icon a=
re
> > corrupted, and the 10 other icons are just a jumble of dots.
>
> > Since the icons in the original seamonkey.exe file are all OK, I have
> > to blame lxlite. =A0
> > I'll play with its settings to see if we can avoid this corruption.
> > If not, we'll just distribute the uncompressed version (it's only
> > 11k larger).
>
> > --
> > =3D=3D =3D=3D almost usable email address: =A0Rich AT E-vertise DOT Com=
 =3D=3D =3D=3D
>
> There was a line in packager.mk that prevented ico and exe files from
> being stripped (compressed by lxlite). Probably the distortion of the
> icons was the reason for it.
> Walter

Found the line
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/pac=
kager.mk#454
PLATFORM_EXCLUDE_LIST =3D ! -name "*.ico" ! -name "$
(MOZ_PKG_APPNAME).exe"
0
Walter
3/2/2011 9:07:58 PM
On Wed, 2 Mar 2011 21:07:58 UTC, Walter Meinl wrote:
> On Mar 2, 10:03�pm, Walter Meinl wrote:
> > On Mar 2, 3:21�am, "Rich Walsh" wrote:
> > > On Tue, 1 Mar 2011 01:28:55 UTC, Peter Brown wrote:

> > > > > Correction: All the above Seamonkey icons now mucked up.
> >
> > > Almost all of the seamonkey.exe icons are corrupt.
> >
> > > Since the icons in the original seamonkey.exe file are all OK, I have
> > > to blame lxlite. �
> >
> > There was a line in packager.mk that prevented ico and exe files from
> > being stripped (compressed by lxlite). Probably the distortion of the
> > icons was the reason for it. 

I did a lot of testing and found that the problem is not lxlite.
It's actually PM's handling of compressed icon resources.

I took the original seamonkey.exe before lxlite and reattached the
icons using 'rc -x2 ...'.  The icons were corrupted.  I also took
the .exe after lxlite and reattached the icons without compression
(i.e. no '-x2').  The icons were OK.

> Found the line
> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#454
> PLATFORM_EXCLUDE_LIST = ! -name "*.ico" ! -name "$
> (MOZ_PKG_APPNAME).exe"

I had removed that in my patch - I'll restore it.  (BTW... lxlite wouldn't
touch *.ico file so the reference is pointless.)


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
3/3/2011 2:16:28 PM
> I did a lot of testing and found that the problem is not lxlite.
> It's actually PM's handling of compressed icon resources.
>
> I took the original seamonkey.exe before lxlite and reattached the
> icons using 'rc -x2 ...'.  The icons were corrupted.  I also took
> the .exe after lxlite and reattached the icons without compression
> (i.e. no '-x2').  The icons were OK.

Are you sure it's that ? I rather have the feeling that it strongly
depends on the version of rc used.
I had cases were only the new rc (version 5.xx) worked ok and I had cases where
only the old rc (version 4.xx) would work.
I never found of a pattern. It was trial and error.
Maybe you also need to use -p if you use -x2 but that's only guesswork.
Maybe it's a bad interaction between the compression done by -x2 and
what lxlite does.
Personally I never had a problem with -x2 as such but I also was not using
lxlite to compress the executable (I just used /E:2 on the linker command line).

Lars
0
Lars
3/4/2011 8:29:45 PM
On Fri, 4 Mar 2011 20:29:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> > I did a lot of testing and found that the problem is not lxlite.
> > It's actually PM's handling of compressed icon resources.
> 
> Are you sure it's that ?

Yes.

> I rather have the feeling that it strongly depends on the version of rc used.

No.

Final analysis:  corruption occurs if the original icon file is more
than 12,288 bytes (12k).

The FF and SM icons have all 4 sizes rendered at 4, 8, and 24 bpp.
I eliminated some of the versions to create a file that was 12,256
bytes.  When attached to the exe and compressed, there was no
corruption.  OTOH, an icon file that was 12,536 bytes showed
corruption on the last icon.  Had there been additional images
after that point in the file, they would have been corrupted too.

I then compared the 8-bit and 24-bit versions and found that they
were virtually identical.  In only one instance could I find any
visual difference:  3 pixels had a nearly imperceptible difference
in the shade of blue-violet that was used.

Since the 24-bit versions of the icons add nothing visually but do
contribute to the problem (though they don't _cause_ it), I think
we should abandon them.  FYI... the 16- and 256-color versions
combined produce a file that's 11,168 bytes.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
3/5/2011 9:23:36 PM
Rich Walsh wrote:

> Final analysis:  corruption occurs if the original icon file is more
> than 12,288 bytes (12k).
>
> The FF and SM icons have all 4 sizes rendered at 4, 8, and 24 bpp.
>
> Since the 24-bit versions of the icons add nothing visually but do
> contribute to the problem (though they don't _cause_ it), I think
> we should abandon them.  FYI... the 16- and 256-color versions
> combined produce a file that's 11,168 bytes.

Considering you can't run a browser at 4bpp or 8bpp, is there any 
disadvantage to dumping those versions instead?
0
Steve
3/5/2011 9:53:18 PM
On Sat, 5 Mar 2011 21:53:18 UTC, Steve Wendt <spamsux@forgetit.org> wrote:
> Rich Walsh wrote:
> 
> > Final analysis:  corruption occurs if the original icon file is more
> > than 12,288 bytes (12k).
> >
> > The FF and SM icons have all 4 sizes rendered at 4, 8, and 24 bpp.
> >
> > Since the 24-bit versions of the icons add nothing visually but do
> > contribute to the problem (though they don't _cause_ it), I think
> > we should abandon them.  FYI... the 16- and 256-color versions
> > combined produce a file that's 11,168 bytes.
> 
> Considering you can't run a browser at 4bpp or 8bpp, is there any 
> disadvantage to dumping those versions instead?

The browser isn't displaying corrupted icons, PM is.

If we removed all icons except the 24-bit versions, they'd look fine
for most of us but would probably look rotten for those running at
color depths less than 16m.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
3/5/2011 11:52:22 PM
Rich Walsh wrote:

>> Considering you can't run a browser at 4bpp or 8bpp, is there any
>> disadvantage to dumping those versions instead?
>
> The browser isn't displaying corrupted icons, PM is.

Right, but the browser runs at the same color depth as PM.

> If we removed all icons except the 24-bit versions, they'd look fine
> for most of us but would probably look rotten for those running at
> color depths less than 16m.

If the 24bpp icons don't display nicely in 16bpp, then that makes sense. 
  Otherwise, my question remains the same.
0
Steve
3/6/2011 2:54:56 AM
On Sun, 6 Mar 2011 02:54:56 UTC, Steve Wendt <spamsux@forgetit.org> wrote:
> Rich Walsh wrote:
> 
> >> Considering you can't run a browser at 4bpp or 8bpp, is there any
> >> disadvantage to dumping those versions instead?
> >
> > The browser isn't displaying corrupted icons, PM is.
> 
> Right, but the browser runs at the same color depth as PM.

What's that got to do with it?  The corrupted icons get displayed by
PM/WPS regardless of whether the mozapp is running or not.  You'd have
the same problem with any app if the aggregate size of its icon were
too large.

If what you're trying to say (in a very roundabout way) is that no one
who runs a web browser has his system set to 256 colors (much less 16
colors), then you're probably right:  the lower color-depth icons will
seldom be needed.  However, they're small while the 16m color icons
are big.  Since they offer no improvement in graphic quality over the
256 color versions, the 16m color icons are the ones to remove if that
will eliminate the corruption issue.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
3/6/2011 6:07:17 AM
Rich Walsh wrote:

> If what you're trying to say (in a very roundabout way) is that no one
> who runs a web browser has his system set to 256 colors (much less 16

Yes.

> colors), then you're probably right:  the lower color-depth icons will
> seldom be needed.  However, they're small while the 16m color icons
> are big.  Since they offer no improvement in graphic quality over the
> 256 color versions, the 16m color icons are the ones to remove if that
> will eliminate the corruption issue.

Fair enough.
0
Steve
3/6/2011 8:36:55 PM
Reply:

Similar Artilces:

superreview requested: [Bug 417590] port Firefox application pane as new helper app pane in SeaMonkey : [Attachment 306521] new applications pref pane, v4
Robert Kaiser <kairo@kairo.at> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 417590: port Firefox application pane as new helper app pane in SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=417590 Attachment 306521: new applications pref pane, v4 https://bugzilla.mozilla.org/attachment.cgi?id=306521&action=edit ------- Additional Comments from Robert Kaiser <kairo@kairo.at> Fixing more nits, carrying forward r+, re-requesting sr. Two problems keep occurring to me with this patch (I start to get unsure if it's my build or the ...

superreview canceled: [Bug 417590] port Firefox application pane as new helper app pane in SeaMonkey : [Attachment 305777] new applications pref pane, v3
Robert Kaiser <kairo@kairo.at> has canceled Robert Kaiser <kairo@kairo.at>'s request for superreview: Bug 417590: port Firefox application pane as new helper app pane in SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=417590 Attachment 305777: new applications pref pane, v3 https://bugzilla.mozilla.org/attachment.cgi?id=305777&action=edit ------- Additional Comments from Robert Kaiser <kairo@kairo.at> Fixing more nits, carrying forward r+, re-requesting sr. Two problems keep occurring to me with this patch (I start to get unsure if it's my bu...

superreview requested: [Bug 417590] port Firefox application pane as new helper app pane in SeaMonkey : [Attachment 305777] new applications pref pane, v3
Robert Kaiser <kairo@kairo.at> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 417590: port Firefox application pane as new helper app pane in SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=417590 Attachment 305777: new applications pref pane, v3 https://bugzilla.mozilla.org/attachment.cgi?id=305777&action=edit ------- Additional Comments from Robert Kaiser <kairo@kairo.at> OK, here's the patch addressing all the recent review comments (unless my post above stated otherwise). Note that I also reworked the type icons in a way th...

superreview granted: [Bug 417590] port Firefox application pane as new helper app pane in SeaMonkey : [Attachment 307255] new applications pref pane, v5
neil@parkwaycc.co.uk <neil@httl.net> has granted Robert Kaiser <kairo@kairo.at>'s request for superreview: Bug 417590: port Firefox application pane as new helper app pane in SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=417590 Attachment 307255: new applications pref pane, v5 https://bugzilla.mozilla.org/attachment.cgi?id=307255&action=edit ------- Additional Comments from neil@parkwaycc.co.uk <neil@httl.net> Note to self: when fixing theme, also ensure 16x16 reserved on menulist itself ...

superreview canceled: [Bug 417590] port Firefox application pane as new helper app pane in SeaMonkey : [Attachment 306521] new applications pref pane, v4
Robert Kaiser <kairo@kairo.at> has canceled Robert Kaiser <kairo@kairo.at>'s request for superreview: Bug 417590: port Firefox application pane as new helper app pane in SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=417590 Attachment 306521: new applications pref pane, v4 https://bugzilla.mozilla.org/attachment.cgi?id=306521&action=edit ------- Additional Comments from Robert Kaiser <kairo@kairo.at> OK, fixed the last few nits (I hope), everything seems to work fine now, carrying forward r+, re-requesting sr ...

[New] Firefox/Seamonkey/Thunderbird Betas
New betas of Firefox, Seamonkey, and Thunderbird are now available. They feature improved video performance and font selection, as well as enhancements featured in previous betas such as printing support and memory management improvements. They also have two known bugs. * Firefox v4.0b8pre: ftp://ftp.netlabs.org/incoming/mozilla/firefox-20101204.zip or http://e-vertise.com/warpzilla/firefox-20101204.zip * Seamonkey v2.1b2pre: ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20101204.zip or http://e-vertise.com/warpzilla/seamonkey-20101204.zip * Thunder...

superreview requested: [Bug 417590] port Firefox application pane as new helper app pane in SeaMonkey : [Attachment 307255] new applications pref pane, v5
Robert Kaiser <kairo@kairo.at> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 417590: port Firefox application pane as new helper app pane in SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=417590 Attachment 307255: new applications pref pane, v5 https://bugzilla.mozilla.org/attachment.cgi?id=307255&action=edit ------- Additional Comments from Robert Kaiser <kairo@kairo.at> OK, fixed the last few nits (I hope), everything seems to work fine now, carrying forward r+, re-requesting sr ...

[New] Firefox 4.0 & Seamonkey 2.1 betas
New betas of Firefox and Seamonkey are now available. They feature native printing support, a major improvement in memory usage, and a fix for a long-time bug. Firefox v4.0b8pre is available from: ftp://ftp.netlabs.org/incoming/mozilla/firefox-20101030.zip or http://e-vertise.com/warpzilla/firefox-20101030.zip Seamonkey v2.1b2pre is available from: ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20101030.zip or http://e-vertise.com/warpzilla/seamonkey-20101030.zip Printing Support ---------------- All native printer drivers will work if their...

superreview canceled: [Bug 379183] port new Firefox page info to SeaMonkey
Daniel Brooks <db48x@yahoo.com> has canceled Daniel Brooks <db48x@yahoo.com>'s request for superreview: Bug 379183: port new Firefox page info to SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=379183 Attachment 275401: 379183-1.diff https://bugzilla.mozilla.org/attachment.cgi?id=275401&action=edit ------- Additional Comments from Daniel Brooks <db48x@yahoo.com> addresses several comments by Kairo ...

superreview denied: [Bug 379183] port new Firefox page info to SeaMonkey
neil@parkwaycc.co.uk <neil@httl.net> has denied Daniel Brooks <db48x@yahoo.com>'s request for superreview: Bug 379183: port new Firefox page info to SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=3D379183 Attachment 275423: 379183-2.diff https://bugzilla.mozilla.org/attachment.cgi?id=3D275423&action=3Dedit ------- Additional Comments from neil@parkwaycc.co.uk <neil@httl.net> >- * The Initial Developer of the Original Code is Daniel Brooks.=0D Isn't it?=0D =0D >+textbox {=0D > background: transparent !important;=0D > border: ...

superreview requested: [Bug 379183] port new Firefox page info to SeaMonkey
Daniel Brooks <db48x@yahoo.com> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 379183: port new Firefox page info to SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=379183 Attachment 275401: 379183-1.diff https://bugzilla.mozilla.org/attachment.cgi?id=275401&action=edit ...

superreview requested: [Bug 379183] port new Firefox page info to SeaMonkey #4
Daniel Brooks <db48x@yahoo.com> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 379183: port new Firefox page info to SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=379183 Attachment 275441: 379183-3.diff https://bugzilla.mozilla.org/attachment.cgi?id=275441&action=edit ...

superreview requested: [Bug 379183] port new Firefox page info to SeaMonkey #2
Daniel Brooks <db48x@yahoo.com> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 379183: port new Firefox page info to SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=379183 Attachment 275762: 379183-4.diff https://bugzilla.mozilla.org/attachment.cgi?id=275762&action=edit ------- Additional Comments from Daniel Brooks <db48x@yahoo.com> now I think it's ready for prime time. ...

superreview requested: [Bug 379183] port new Firefox page info to SeaMonkey #3
Daniel Brooks <db48x@yahoo.com> has asked neil@parkwaycc.co.uk <neil@httl.net> for superreview: Bug 379183: port new Firefox page info to SeaMonkey https://bugzilla.mozilla.org/show_bug.cgi?id=379183 Attachment 275423: 379183-2.diff https://bugzilla.mozilla.org/attachment.cgi?id=275423&action=edit ------- Additional Comments from Daniel Brooks <db48x@yahoo.com> addresses several comments by Kairo ...

Web resources about - [New] Firefox and Seamonkey Betas - mozilla.dev.ports.os2

The Hawaiian Seamonkey
Diving, eating, gardening, loving the Big Island of Hawaii

The SeaMonkey® Project
The SeaMonkey project is a community effort to develop the SeaMonkeyall-in-one internet application suite (see below).Such a software suite was ...

SeaMonkey - Wikipedia, the free encyclopedia
cross-platform Internet suite . It is the continuation of the former Mozilla Application Suite , based on the same source code. Core Mozilla ...

Review: SeaMonkey 1.1.8 for the Mac
SeaMonkey 1.1.8, the Mozilla Foundation's all-in-one Internet application, combines browsing, e-mail, HTML editing, and IRC chat.

SeaMonkey 2.3 Beta 1 arrives for testing
Based on the same Gecko browser engine as Firefox 6, SeaMonkey 2.3 Beta 1 has been released for testing. It offers improvements to WebGL that ...

SeaMonkey Offers Browser, E-Mail, and Chat
... resuscitated a group of Internet tools built by Netscapewhose spin-off, Mozilla, brought out the popular Firefox Web browser. Renamed SeaMonkey ...

SeaMonkey, Mozilla's all-in-one Internet suite, releases new beta
The SeaMonkey Project has released SeaMonkey 2.1 Beta 3 , a version that makes a lot of new functionality available to a wide audience for the ...

SeaMonkey review
Browse the web, work with mail, chat in IRC and edit HTML

SeaMonkey 2.33
... advanced e-mail, newsgroup and feed client, IRC chat, and HTML editing made simple, all your Internet needs in one application. The SeaMonkey ...

Seamonkey 1.1 Released
stuuf writes "Version 1.1 of the Seamonkey Internet Application Suite is now available, with quite a few improvements over the 1.0 series. Some ...

Resources last updated: 12/17/2015 6:45:42 AM