User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a) Gecko/20040416 MultiZilla/220.127.116.11d Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a) Gecko/20040416 MultiZilla/18.104.22.168d 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....
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.
(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/22.214.171.124p 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.