Closed Bug 242422 Opened 20 years ago Closed 15 years ago

Print prepare takes 4 min 45 sec and prevents focus change

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
Other
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ygk, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a) Gecko/20040416 MultiZilla/1.6.3.1d
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a) Gecko/20040416 MultiZilla/1.6.3.1d

When printing this page or other large pages the print dialog box with the word
preparing comes up and the ability to switch to other tasks is unavailable.
CTRL-ESC brings up a diaolog saying printing is not responding and the
opportunity to close the application after about 30 sec but if I wait
approximately 4 min and 45 sec the print dialog changes to progress bar and the
page prints. The length of the wait appears to be proposional to the size of the
page. (Some where the printout is 70+ pages take 15+ minutes). This also occurs
in firefox 0.8 for OS2 and while the focus lock also occurs in Win NT using
Mozilla 1.2b it only take 20-30 seconds

Reproducible: Always
Steps to Reproduce:
1. Select a large web page for printing (like url provided)
2. Print
3. Focus is lost making the computer unusable for a prolonged period

Actual Results:  
Focus is lost making the computer unusable for a prolonged period


Expected Results:  
Focus should return immediately allowing other tasks to be performed

This bug might be related to bugs 161504, 206259 or 211813
I'm seeing Mozilla itself lock up for the 20-30 seconds you mention on Linux
(probably as we set up the frame tree and reflow it, though I'm not sure).

I don't know what else we do during the preparing stage, though, especially what
platform-specific stuff....
Summary: Print prepare takes 4 min 45 sec and prevents focus change → Print prepare takes 4 min 45 sec and prevents focus change
I tryed printing the above listed page again with 1.7 RC1 it took 4 minutes and
15 sec in print prepare during which all focus was lost. I then disabled the
latest innotec font engine the print prepare took 1 min and 15 sec still an
unreasonable length of time to have an unusable computer but it indicates that
the font engine is a significant contributor to the problem. I then tryed
reducing mozilla's priority to idle and printing while I could then change focus
the change occured so slowly that it functionaly rendered the system unusable.
Maybe something has changed from the version Gregg used, I don't see a big
problem (any more). I printed the os2warp.be page a few times to the spooler: it
took about 10s for the scrollbar to appear in the printing dialog and after that
Mozilla itself was usable again for the remaining 20s. Within these 10s CPU was
at 100%, after that it was low <30%. And could use both Mozilla and the rest of
the Desktop fine in that time. For the 51 pages that it prints I don't think
that  30s are excessive, but I guess that's also a matter of hardware (Athlon XP
running 2133 MHz here).
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a2) Gecko/20040605, with the
Innotek Font Engine installed.
Gregg, do you still see the big difference in speed when compared to the Windows
version when using a recent nightly? If so, what is your hardware?
(In reply to comment #4)
> Gregg, do you still see the big difference in speed when compared to the Windows
> version when using a recent nightly? If so, what is your hardware?

I tryed using the 8/6/04 nightly. The test page I listed took 50 sec in print
prepare on OS2 and 20 sec on WinNT. I tryed two larger pages (propriatary 27&59
pages)it took 2 minutes 30 sec/10 mins in OS2 and 40 secs/5mins on WinNT. This
is on a PIII 500 with 256mb of ram. However WinNt is running in virtual PC on
OS2 and has only 64mb of ram allocated to it. Clearly the changes made have
improved the performance. One other thing I noticed was that the print prepare
dialog didn't appear in OS2 but it did on WinNT. Thanks

    


It seems to me that this problem is related to the more general problem of the
OS/2 version that it displays long webpages slower than other platforms, e.g.
bug 258136. Rendering to the printer is probably not much different from
rendering to the screen?!
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

No, this seems to me like a valid bug report and while I cannot reproduce it
fully, the relationship to bug 258136 should be confirmed or refuted before
resolving it, so for now I mark it NEW and mark dependency.
Status: UNCONFIRMED → NEW
Depends on: 258136
Ever confirmed: true
(In reply to comment #8)
> No, this seems to me like a valid bug report and while I cannot reproduce it
> fully, the relationship to bug 258136 should be confirmed or refuted before
> resolving it, so for now I mark it NEW and mark dependency.

This bug is improved using above URL but still not resolved. In Mozilla/5.0 (OS/2; U; eCS 1.2.1; en-US; rv:1.8) Gecko/20051106 MultiZilla/1.8.1.0p SeaMonkey/1.0b the print prepare doesn't show a dialog box but it takes 1 min 10 sec and will not allow a focus shift. I still have some large propriatary database prints where print prepare take more than 10 minites with no ability to shift focus.  
OK, now that we solved bug 258136 (which probably _is_ different that this one, I don't think the printing codepath asks for mouse or keyboard activity, although I might be wrong), we can look at this again.

I just printed the os2warp.be page using SeaMonkey 1.1.12 and the latest OS/2 nightly of SeaMonkey 2.0a2pre and didn't see any big delay any more. I timed it as approximately 6s, and I was running a build in the background so it was slower than normal. And it didn't block the UI at all. So I think this is WORKSFORME by now.
I haven't noticed any such problems any more -> WFM.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.