Closed Bug 209970 Opened 22 years ago Closed 21 years ago

Mozilla hangs when printing from Ovid's WebSPIRS online databases

Categories

(Core :: Printing: Output, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 205781

People

(Reporter: p_horner, Unassigned)

References

()

Details

(Whiteboard: Test URL http://web5.silverplatter.com/webspirs/start.ws is only valid for ONE MONTH)

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 I am alerting you to a problem with WebSPIRS online Web database product by Ovid (www.ovid.com) which is used in many academic and public libraries. We have tested Mozilla versions 1.21 through 1.5a (latest release) on both MS Windows and Linux and have found a problem with printing. When you want to print a record, you press the PRINT button in the WebSPIRS window. At this point it looks like some JavaScript launches the Mozilla printer dialog box. After you select "Print" it looks like the record tries to download from WebSPIRS to print. The Mozilla print engine hangs in a "Processing..." state and basically never prints the record. If a person does not select the PRINT button in WebSPIRS but instead selects the PRINT PREVIEW button, the record then downloads to Mozilla and is displayed on the screen. If you now press the PRINT button in WebSPIRS, the record has already been cached in memory and the Mozilla print dialog box comes up and after pressing "Print" it processes and prints normally. This really seems to be an issue with how the Mozilla print processor processes a print job. The problem happens using LPR, lprNG, and CUPS. It seems the print process is trying to start using just a header from the receiving (downloading) print record. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: mozilla hangs in a print processing state. Expected Results: the print job should have been submitted
We need a small testcase (if possible). Do you get the document from a HTTPS or Http server ?
In order to reproduce this case, one needs access to a WebSPIRS database product. This is a subscription product for full-text and abstract journal and magazines sold by www.ovid.com Most academic university libraries subscribe to this product. The unfortunate thing is that since it is subscription based and requires authentication, only those who have access to a valid license can connect. Ovid has been alerted of this issue and is not concerned since they only support IE and Netscape 3.01 through 4.7x. Many libraries are switching to Mozilla because of its rich feature set. It is a critical issue if one cannot print the information retrieved.
Access to WebSPIRS is done via http:// request and not https
I don't have a JavaScript stack dump, but I did step through the code. It looks as if WebSpirs is trying to open a hidden frame and then call frame.print() on it. At this point Mozilla just hangs indefinitely at the "Preparing..." dialog. I'll keep working on seeing how the frame is created, but it seems as if they're trying to obfuscate the code somewhat.
I have obtained a test account from Ovid for the WebSPIRS product so that the Mozilla developers can test this problem and hopefully find a solution. To recap: 1. Search the database and find a record to print 2. Press the WebSPIRS supplied "print" button 3. Answer any additional criteria on what to print from the record 4. Press the WebSPIRS supplied "print" button 5. An invisible window will open and the record to be printed will download into the invisible window. Mozilla will try to print the data from the invisible window and hang in-process. If a user selected the "print preview" button instead of the "print" button, the record to be printed will load into a visible window and print normally. It is the invisible window that is the problem. Many libraries are switching to Mozilla and this is a problem with all versions and platforms of Mozilla. Test Account Access (valid for 1 month): Database: WebSPIRS ERIC URL: http://web5.silverplatter.com/webspirs/start.ws Username/password: mozillatest/testing -Perry Horner
Addendum: The test account is valid for ONE CONCURENT USER only. So if somebody is using it, others will not be able to access until that person logs out. -Perry Horner
This bug is still critical for library users of Mozilla. The demo account will expire the beginning of August so I hope somebody in the development tree can reproduce this problem and fix it.
confirming with a win2k trunk build. It hangs in a thread and I'm to dumb to generate a stack trace for this ...
Keywords: hang
Keywords: stackwanted
Whiteboard: Test URL http://web5.silverplatter.com/webspirs/start.ws is only valid for ONE MONTH
I have requested that the WebSPIRS test account be extended another month. This problem must be resolved.
I tried to generate a stack trace for the hang, but: The account mozillatest has been denied access to Server erl.silverplatter.com: User account disabled
The test account has been reactivated. The person at Ovid was on vacation and did not get to it until today. People should be able to test the problem by: 1. Search the database and find a record to print 2. Press the WebSPIRS supplied "print" button 3. Answer any additional criteria on what to print from the record 4. Press the WebSPIRS supplied "print" button 5. An invisible window will open and the record to be printed will download into the invisible window. Mozilla will try to print the data from the invisible window and hang in-process. If a user selected the "print preview" button instead of the "print" button, the record to be printed will load into a visible window and print normally. It is the invisible window that is the problem. Many libraries are switching to Mozilla and this is a problem with all versions and platforms of Mozilla. Test Account Access (valid for 1 month): Database: WebSPIRS ERIC URL: http://web5.silverplatter.com/webspirs/start.ws Username/password: mozillatest/testing
oh... this it not really a hang... just the printing engine seems to hang for some reason, but mozilla continues to work just fine this means that I can't generate a stacktrace. someone who knows mozilla's printing engine will have to look at this.
Keywords: hang, stackwanted
This bug is very similar to bug #205781 There is a test file (zipped) that is available for bug#205781 that can be used to diagnose this bug's [209970] problem.
*** This bug has been marked as a duplicate of 205781 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.