Firefox 4/5/6.0.1 printing on Solaris 10 slow

[Ignatios Souvatzis]

Hi,

printing a web page from Firefox 6.0.1 /Solaris 10/Sparc[1] is often
incredibly slow. That is: when the print progress pop-up is enabled, it
progresses through the pages, then waiting at before (or sometimes
after) the last page for lots of seconds to several minutes.

It's not starting the underlying lpr that slows down; I've checked this
by replacing it by a shell script that /bin/cat-s to a temporary, then
starts lpr in the background, and logs progress...

I've seen this occasionally before FF6.

All users, from time to time, not all users at the same time.

hm, could it be some resource starvation with pipes? How would I
check this? Any other idea?

(It can't be memory starvation - The machine normally has 10 GB unused).

-is


[1] This is

instein 5 # pkginfo -l SFWfirefox
PKGINST: SFWfirefox
NAME: Mozilla Firefox Web browser
CATEGORY: GNOME2,application,JDSosol
ARCH: sparc
VERSION: 6.0.1,REV=110.0.4.2011.08.31.19.11
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: Mozilla Firefox Web browser
PSTAMP: grandslamsun20110831221922
INSTDATE: Sep 06 2011 13:29
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 88 installed pathnames
7 shared pathnames
22 directories
27 executables
158014 blocks used (approx)

[John D Groenveld]

Post by Ignatios Souvatzis
It's not starting the underlying lpr that slows down; I've checked this
by replacing it by a shell script that /bin/cat-s to a temporary, then
starts lpr in the background, and logs progress...

Investigated the PostScript generation via print to file?

Is there a certain page size, number/resolution embedded graphics,
font that trips the bug?
Can you provide a link to your debugging example?

Post by Ignatios Souvatzis
instein 5 # pkginfo -l SFWfirefox
VERSION: 6.0.1,REV=110.0.4.2011.08.31.19.11

6.0.2 is up:
<URL:http://releases.mozilla.org/pub/mozilla.org/firefox/releases/>

John
***@acm.org

[Ignatios Souvatzis]

Post by John D Groenveld

Post by Ignatios Souvatzis
It's not starting the underlying lpr that slows down; I've checked this
by replacing it by a shell script that /bin/cat-s to a temporary, then
starts lpr in the background, and logs progress...

Investigated the PostScript generation via print to file?

Yes. AFAICT, it works fine.

Post by John D Groenveld
Is there a certain page size, number/resolution embedded graphics,
font that trips the bug?

No. Happens with any HTML source, big or small, even when empty.

Post by John D Groenveld
Can you provide a link to your debugging example?

I've seen it even with about:blank

Post by John D Groenveld

Post by Ignatios Souvatzis
instein 5 # pkginfo -l SFWfirefox
VERSION: 6.0.1,REV=110.0.4.2011.08.31.19.11

<URL:http://releases.mozilla.org/pub/mozilla.org/firefox/releases/>

Thanks. I meant to hunt that down today, but got distracted by other important
tasks like the above brought to my attention.

-is

[Ignatios Souvatzis]

Post by Ignatios Souvatzis

Post by John D Groenveld

Post by Ignatios Souvatzis
It's not starting the underlying lpr that slows down; I've checked this
by replacing it by a shell script that /bin/cat-s to a temporary, then
starts lpr in the background, and logs progress...

Investigated the PostScript generation via print to file?

Yes. AFAICT, it works fine.

Post by John D Groenveld
Is there a certain page size, number/resolution embedded graphics,
font that trips the bug?

No. Happens with any HTML source, big or small, even when empty.

Post by John D Groenveld
Can you provide a link to your debugging example?

I've seen it even with about:blank

Post by John D Groenveld

Post by Ignatios Souvatzis
instein 5 # pkginfo -l SFWfirefox
VERSION: 6.0.1,REV=110.0.4.2011.08.31.19.11

<URL:http://releases.mozilla.org/pub/mozilla.org/firefox/releases/>

Thanks. I meant to hunt that down today, but got distracted by other important
tasks like the above brought to my attention.

6.0.2: no change.

-is

[Ignatios Souvatzis]

Post by John D Groenveld

Post by Ignatios Souvatzis
It's not starting the underlying lpr that slows down; I've checked this
by replacing it by a shell script that /bin/cat-s to a temporary, then
starts lpr in the background, and logs progress...

Investigated the PostScript generation via print to file?
Is there a certain page size, number/resolution embedded graphics,
font that trips the bug?
Can you provide a link to your debugging example?

Post by Ignatios Souvatzis
instein 5 # pkginfo -l SFWfirefox
VERSION: 6.0.1,REV=110.0.4.2011.08.31.19.11

<URL:http://releases.mozilla.org/pub/mozilla.org/firefox/releases/>

News: with 7.0.1, that problem is gone. In exchange, it is dead slow,
especially compared to 6.0.x, which was pretty fast (for a recent firefox).

*sigh*

-is

[John D Groenveld]

Post by Ignatios Souvatzis
News: with 7.0.1, that problem is gone. In exchange, it is dead slow,
especially compared to 6.0.x, which was pretty fast (for a recent firefox).

Thanks for the heads-up regarding 7.0.1.

No noticeable performance degradation on Solaris 10 and 11x x64.

I think the Solaris engineers who build the SFWfirefox packages
participate on OpenSolaris.ORG's desktop-discuss mailing list.
Perhaps they can help you diagnose.
John
***@acm.org