Closed Bug 87788 Opened 23 years ago Closed 23 years ago

Printing with WordPerfect 2002 while Mozilla is running opens 30+ browser windows

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: thomas.swan, Assigned: law)

References

Details

(Keywords: dataloss, Whiteboard: [ADT3])

Attachments

(2 files, 2 obsolete files)

messages processed by mozilla during WP print operation
78.95 KB, text/plain
Details
Patch, not tested yet with WP
841 bytes, patch
deanis74
: review+
jag+mozilla
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Always reproducible. Open WordPerfect 2002 before or after Mozilla (Build 2001062504) Print a document within WordPerfect and Mozilla will launch a bunch of browser windows (on average 20+). I think this first happened about a week ago, but I didn't attempt to reproduce it as I though it was one of the great banner ad scams. Sorry for the tardy bug report. I don't know of any other apps that combine with Mozilla to cause the same problem, but then I don't print many things...
-> XPApps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
QA Contact: sairuh → sujay
The user is claiming that he is printing from WordPErfect, not Mozilla. Not sure if I'm reassigning to the right person, John can you make the necessary changes to this bug report. thanks.
Assignee: pchen → danm
QA Contact: sujay → jrgm
Component: XP Apps → XP Toolkit/Widgets
I think XPApps is the right place (probably something to do with content handler). danm the manm deals with how windows open, not why they open.
Assignee: danm → pchen
Component: XP Toolkit/Widgets → XP Apps
QA Contact: jrgm → sairuh
Well, if there's anything more I can do to help figure it out. Let me know. Right now, I'm at a loss.
I can confirm this behavior on Windows 2000 using Moz build 2001062604. It happens just as Thomas describes it. It is really nasty since it effectively makes the computer unusable. On my .5gb machine I got down to 17mb before the OS decided Moz was in a bad way and let me kill it.
I have 1G ram and that's how I survived a double onslaught
On a smaller box (128M) it locked up my machine today. That's why I'm saying its more than a normal (severity) bug. If I'm wrong, someone please correct me.
Severity: normal → major
I considered doing same but thought it better for Thomas to do it. Our users are almost all WP2k and NS4.7; we'll upgrade to WP2002, and NS has to play nice in that environment. Interestingly, I've seen WP go dead after NS6.x is installed to a machine. The next attempt to run WP then succeeds. I didn't think anything of it at the time, but now wonder if there are more interactions.
*** Bug 91308 has been marked as a duplicate of this bug. ***
confirming based on the dupe
I am confirming this on my win98se machine
additional info : the first time it happenned to me it caused WP2002 to crash (the first crash I got so far). I thought it was ad banner scam at first too so tried to close some windows to no avail. I didn't notice any new error entry in the javascript console (I suspected javascript to spawn new windows for an unknown reason). Also, you don't really have to print to cause this bug, I just tested it with my printer offline ans it seems the spooling process was enough to trigger the bug, even if my printer didn't print anything. Maybe check the way mozilla is interacting with the spooling process in Windows ? WP2002 spools documents through it's perfectprint service, which is a bit different from the normal Windows spool process.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I just got the same result after choosing "Publish to PDF" on a 1 page document. About 30 mozilla windows appeared in a short time as described above. It seems it isn't just caused by printing then... I tested it a second time to see if it was reproducible and it was, but this time it also crashed mozilla : MOZILLA a causé une défaillance de page dans le module PLC4.DLL à 017f:60ed101b. Registres : EAX=00000001 CS=017f EIP=60ed101b EFLGS=00010202 EBX=03ac0fc0 SS=0187 ESP=0068f8b8 EBP=0068f8e0 ECX=00000001 DS=0187 ESI=03ac0f90 FS=301f EDX=03ac0f4c ES=0187 EDI=00000001 GS=21af Octets à CS : EIP : 8a 11 8b c1 84 d2 74 08 8a 50 01 40 84 d2 75 f8 État de la pile : 60ed112c 00000001 60f0b534 03ac0f90 600a8a45 00000001 00000000 0068fa28 00000000 00000000 0068f970 00404eb7 03ac0f90 00000000 03ac0fc0 0068fa50 BTW, I also want to point out my last comment above that says I'm on Win98SE and the OS' section only mentions Win2000
I forgot something again in my comment just above (2001-07-28 22:08) : Buils 2001072808
On the opposite, could that be a WP10 bug and not a mozilla bug ?. I raised the question in the WP10 newsgroups a minute ago to see what feedback we will get from there. WP10 newsgroups can be found at news://cnews.corel.com/corel.wpoffice.wordperfect10 Look for messages 2001-07-18 13:18 and 2001-08-15 01:48 BTW, stills occurs in today's trunk builds 2001081403, I'll post a Talkback bug ID shortly for the stacktrace. (as noted in my comment above, it sometimes crashes in pcl4.dll)
Talkback bug Id TB34125540M
Seems to be related to the turbo mode. I turned mine off and the problem was gone. It also has been reported in NS 6.1. It probably is related to WP's print spooler, but if possible, would be a much quicker fix on this end. Corel is due to have a SP out within a month if they keep to their schedule. Rumor has it that printing is a big priority.
jrgm, d'you think this is turbo-related?
Reeseco: So, is it confirmed that Corel is working on this at their end as well? In a show of inter-company comradery, perhaps the Corel and Mozilla developers could work together to get to the bottom of this.
I don't believe this is turbo related--I do not have turbo on and yet experience the behavior any time I either print or make a PDF from wp10. OS is win2k.
This problem occurs both in Turbo and regular mode on Win2K
Corel is working on printing issues in general. A look at their newsgroups show the problems some are having with WP's print spooler. As to whether this solves anything, I don't know. Strangely, when I reinstalled and turned off the turbo mode (I couldn't find anywhere else to turn it off), the problem went away. It could've just been the reinstall, but I did notice comments on Wordperfect's newsgroups indicating that turning off turbo solved their problem too.
It's in edit | preferences | advanced | Enable quick launch About the turbo switch issue, I mean I don't get this problem if not using quick launch and mozilla isn't running. WP10 doesn't open mozilla by itself. But printing from WP10 while mozilla *is* running, turbo switch or not, causes this problem. Those with turbo switch enabled automatically get the problem as mozilla is running in background, but when Quick launch is disabled, the problem occurs only when mozilla is already running.
Punting to trudelle because I'm not quite sure what to do with this bug. ;-)
Assignee: pchen → trudelle
*** Bug 103098 has been marked as a duplicate of this bug. ***
Sounds like a Windows integration issue, ->law
Assignee: trudelle → law
*** Bug 103320 has been marked as a duplicate of this bug. ***
This one wins the "weird bug of the week" award.
Target Milestone: --- → mozilla1.2
cc: timeless in case he has any ideas
I've seen reports of this being fixed with the newly released Wordperfect SP2, though I don't have SP2 yet to test it myself.
Only printing from wp10 causes this behavior on my machine, and there are no other reports of it in this bug. So if Corel's SP2 fixes it, that might be the end of it. But what about the many people who never get service packs? If there is a Moz change that would bypass this problem for them, it might be good to apply it.
Corel's WordPerfect 2002 SP2 does not seem to correct the perverse interaction between printing and moz/ns--not for me, anyway. I have a fresh xp pro machine (not upgraded, wiped clean first), brand new Moz install and profile, and Corel's WordPerfect Office 2002 SP2 CDs (fresh CDs). With all that installed, I get the 30 or whatever Moz browser windows when I print and made a PDF from WP.
*** Bug 108463 has been marked as a duplicate of this bug. ***
*** Bug 105384 has been marked as a duplicate of this bug. ***
Ok, I cinfirm, now that I have it, that wordPerfect 10SP2 doesn't address this issue. According to this newsgroup post however, it seems that the problem didn't occur with NS 6.2 and WordPerfect 10 SP2. Maybe you can look what netscape has done to get rid of the problem ? news://cnews.corel.com:119/3C032F1F.B05C955E@corel.ca
I have exactly the same problem. Always reproducible. If Mozilla 0.9.4 is open and I have Wordperfect 10 (ie 2002) open as well then if I choose to print a document from within WordPerfect then around 20 instances of Mozilla are launched. About 1 in 20 times Mozilla crashes but mostly I have to manually close the Mozilla windows one by one. I am running Windows 2000 SP2. I also have the latest service pack from Corel (WP2002 SP2) but the problem persists. Andrew Steele
I made a small error in my previous post.... I have Mozilla 0.9.6 build 2001112009 Andrew
*** Bug 114364 has been marked as a duplicate of this bug. ***
*** Bug 114605 has been marked as a duplicate of this bug. ***
Related to COMMENT 12: From the Corel newsgroups i got this: "PerfectPrint is the print engine: preps the data to send to the print process, back and forth information to and from the printer driver (WYSIWYG is intensive... and since most MS products are NOT WYSIWYG.. then you need a middle app... Then the data is spooled in the windows print process... spooling attributes controled in Windows (the printer driver really) stuff like RAW or EMF, or NOT to spool and print directly to the printer.... WP uses the Windows print process and spooling is managed and done by Windows itself... spools.exe and spool32.exe" So i guess we should rule out the WP printer spooling. I will install Netscape 6.2.1 shortly, to see if they indeed fixed it.
*** Bug 117833 has been marked as a duplicate of this bug. ***
* Printing from WP2002 (SP2), with Netscape 6.2.1 (with quick launch enabled) works just fine. * Printing from WP2002 (SP2), with Mozilla 0.9.7 (with quick launch enabled) causes a mess. So i guess the problem really 1. is Mozilla specific, and 2. still persist after applying WP 2002 Service Pack 2 Removed Mozilla from my computer at work (in favor of Netscape) cause i can't have Mozilla bringing down my computer whenever i try to print. Will keep on testing on my Home computer.
If quick launch is enabled that means that Mozilla is running and in memory. The problem that I originally described occurs when Mozilla is running and WordPerfect are running simultaneously, hence a few of the comments about quicklaunch making a difference. If the mozilla process is not running (verify w/ task manager) then Mozilla is not opened a bizillion times when you try to print; everything acts normal. The flipside of that is when mozilla is running (either as quicklaunch or as a normal window) and you try to print from WordPerfect then the windows just won't stop opening until you kill the process. This also occurs when publishing to a PDF file. So it seems like Mozilla is "intercepting" something between WordPerfect and the PerfectPrint engine although I doubt that is exactly what's happening.
So i was right saying that this doesn't happen with netscape 6.2... does anyone who worked on the netscape 6.2 release willing to either fix this or give a hint to where toe problem may be for another person to fix it ?. This is very annoying bug in my opinion and I think should have higher priority and/or lower target milestone.
Same (reproducable) error here. Mozilla 0.9.7 and WPO2002 with SP2 installed. Not using 'Turbo mode'. This is irritating :(
I discovered last night that this behavior is not confined to WP but also to the other apps in the Corel suite. For example, the Publish to PDF function in Presentations brings forth the same xx Mozilla windows.
All WPOffice 2002 / WP10 components apparently cause the problem while printing, because they use a common print engine. Note that CorelDraw10, from which I believe the WP10 print engine was partially derived, does not display this problematic interaction with Mozilla. I have monitored the registry and file activity of WP10 using the tools from Sysinternals (about the limit of my technical abilities), but could not discern anything that gave me a clue what was going wrong.
any word yet from the netscape people? They already solved (or circumvented) the problem, so why try reinventing the wheel?
I hate to suggest this, but is might be sensible to put this in a dataloss category. Most machines do not have a large amount of memory, thus become unresponsive, sometimes to the point of a virtual system lock. I've had two Win98 machines and on Win2K machine become so unresponsive that the only solution was to hit the reset button. After which I lost the work I had done since the last save (thank goodness for timed backups.) When this happens while a timed backup takes place, the data can be lost completely (again, with the exception of the most recently saved file.) IMHO, I think this should be a 1.0 bug not 1.2
For those of us who participate in the selection of software, having this repaired would be fantastic, since it makes our decision easier on software easier. I hope one of Corel or Moz/Netscape will tackle this soon...
I want to echo other people's comments. This is a severe bug that causes data loss under Windows. I would like very much to have a browser as a default that offers stability, good page rendering, and security. The Word Perfect printing problem prevents my using Mozilla, except under certain limited circumstances. This bug needs a high priority.
Although already somewhat thoroughly covered, I wanted to also say that I see the same behavior in WP10 +SP2, and have "Quick Launch" activated. (BUILD 2002011703)/Windows XP. Although I can usually get around this with a quick <CTRL><ALT><DEL> and close Mozilla's main process when several Mozilla windows spawn. Has anybody worked up a good conspiracy theory yet on how this can be something caused by Microsoft (It is interesting how this seems to happen only to users of Microsoft's closest competitor(s) in Word Processing and Internet browsing) At the very least, a good conspiracy theory can be entertaining (while also being infuriating to some...)
Can somebody tell me if the problem comes and goes depending on whether you check/uncheck everything under Prefs-Advanced-System?
With everything unchecked in the Preferences, Advanced, System, I get lots of open instances of Mozilla when printing with Word Perfect 10. With everything checked, I get the same results.
Thank you. That eliminates one possible conflict, at least. This should not be my bug. If only I had somebody else to pawn it off on. Has *anybody* tried this under a debugger and try to figure out why we're opening windows? We're getting some bogus DDE request, or something. I'll have to install the trial version and give it a go, I suppose.
Confirming, I have never had Mozilla registered to open any file types but the interaction problem with WordPerfect10 printing has been consistent. I also just took a quick look at all references to Mozilla in the registry to see if it could somehow get unexpectedly associated with a file type through some means and found that there are no such errant entries.
i have wp8 and ddespy so i should probably be able to debug this.. if someone suggests steps i'll try..
i'm not sure if you'll be able to duplicate this error with WP8. From my experience, and what i see from others as well, is that the error only occurs with WP2002 (regardless of the service packs)
I believe Patrick is correct--I never experienced this with Moz and WP9, only Moz and WP10 (aka Wordperfect 2002).
Corel introduced major changes in the printing system used by the components of Corel/WordPerfect Office in version 2002/10. It is this printing system only that has the disastrous interaction with Mozilla.
From the Corel WordPerfect Newsgroup. I haven't tried it myself, just posting it FYI. <quote> Any of you using Mozilla out there know of the goofy bug where a WordPerfect Print command spawns dozens of Mozilla windows uncontrollably. Until Corel and/or the Mozilla organization get this fixed, I've got a workaround: I have uploaded a new set of macros to my Web site, called "MozPrint" (for Mozilla Print). What they do is check to see if there are any Mozilla windows are open before printing, then close them automatically (or not, depending on your choice). There are five macros: the main one, "MozPrint.wcm," and four that call the main one for different jobs: "MozPrintDialog" (calls print dialog), "MozPrintPage" (prints current page), "MozPrintDoc" (prints full document), and "MozPrintPDF" (publishes to PDF). Use them in lieu of the regular Print commands, and at least you won't accidentally trigger that annoying bug. Readme.wpd file included, and let me know your reactions or suggested improvements. Macros & Tips: http://members.aol.com/mkoenecke </unquote> Just out of curiosity. Is someone actually WORKING on this bug? It's assigned to Bill Law, but Bill indicated that this actually shouldn't be his bug.
*** Bug 123361 has been marked as a duplicate of this bug. ***
I just stumbled upon this bug. Very interesting. I wonder if WP could be sending out some sort of DDE command, except broadcast instead of targeting a specifc app. I don't think Mozilla responds to DDE commands quite properly, as evidenced by two windows opening whenever I click on a link in Outlook. Just a thought.
<caveat>I am not an expert, and my opinions may not fit drivers' ideas. If the Outlook problem is unrelated to the WP, then my comment is worth little.</caveat> If we've got major problems like this covering more than one app, as Dean Tessman claims, then this ought to be nominated (and targeted) for 1.0 and given critical or blocker severity. Word processing and email client apps now known to cause this type of behavior- how many apps will do this? Do we have any idea? We can't test every action in every app ever written for windows and put up notices saying "you can't do x in 'appname' with mozilla running" for each one which turns out to cause wacky behavior, and this is going to need to be fixed on our end, even if it is the WP devs' and Outlook devs' (and who knows how many others') fault.
if dean's right, and we're all starting to suspect it, then any of the other bugs already targetted for earlier will magically solve this problem. If that happens, then there would be no reason to move this bug to an earlier target. If dean's wrong, then we've just asked someone to spend time on a much less important bug. bottom line: if someone has the time to work on this, please do so.
I wish I had the expertise to address this from the Mozilla side, but it seems to me that the most profitable line of inquiry is to figure out how Netscape 6.2's handling of DDE interrupts differs from the base Mozilla code. It's got to be something triggered by the POP100 (Perfect Office Print 10.0) printing module, and the DLL calls from that are readily discernible. I'm concerned, since this is targeted for 1.2, meaning we probably will not see a fix for a couple of years. Failing that, I would at least like to make my "MozPrint" macros bulletproof, but have one big problem: I do not know how to close the Mozilla QuickLaunch stub, since PerfectScript only offers a way to target applications by their window handles. (You can look at the macro code; it's quite simple.) If someone could clue me in to some Windows command line I could run to close the QuickLaunch stub, the macro would take care of the problem fairly satisfactorily. As it stands, for all to work okay one has to close QuickLaunch manually.
"mozilla -kill" will end turbo. It does not close the running mozilla session.
Thanks! I've uploaded MozPrint.zip, version 1.1, which shuts down the Quicklaunch stub, just now. For some reason it seems to drag down system performance somewhat after executed, so I may still do some tweaking. But it works.
I am not sure I entirely follow some of the recent comments on this issue, so let me say a few things in response, with the proviso that anyone should feel free to offer corrections to my errors. First, it was my understanding that the problem concerns what so far appears to be a unique interaction between the WPOffice2002/10 printing system and Mozilla. When printing from any of the main components of WPOffice/10, if Mozilla is running it will begin to open windows which it continues to do until reaching some limit defined by resources, memory, or something else. As far as I have seen, no other program has had this effect on Mozilla (is that not correct?). Equally, WP10 printing does not have this effect on any other program, in particular it has no comparable effect on any other browser. Also, the effect is entirely unrelated to Mozilla having associations registered for it to be opened for any file types--it happens when absolutely no associations are registered for Mozilla. Second, while the macros Michael Koenecke has devised are clever and neat, they are not really a response to the issue for most people, I suspect. First, they are aimed at WordPerfect, the word processing component, while the issue also concerns the other components of the suite, in particular QuattroPro and Presentations. Second, for many of us having to remember to use a printing macro to close Mozilla before you print is not much of an improvement over having to remember to close Mozilla manually before you print normally. Its really just a neumonic aid that works under some circumstances for some people to help them remember the possibility of the disastrous interaction before they cause it to occur. Presumably this really just needs someone who knows what they are doing do identify what is causing the interaction by causing it under a debugger. Then the relevant code can be compared between Mozilla and Netscape6.2? No? Of course, I do not know what I am doing, so .... Depending on the kindness of strangers.
*** Bug 124176 has been marked as a duplicate of this bug. ***
Warning, bug 99940 (as currently summarized ...) is going to change the behavior of -kill.
Interestingly enough, although I thought this bug was prevalent under all WP2002 components, I just printed from Quatro Pro 10 with no problems with quick launch enabled. And, as I am making this comment with 3 current Moz windows open, printed again from Quattro Pro 10 with no adverse effects. OTOH, I, too, get two Moz windows for every click in my email app on a clickable link. Actually, that is not entirely true, I sometimes get only one, but have been unable to determine what the difference could be in the links I click. Of course, that is likely to be the topic of another entirely different bug...
Jim Smith is correct, QuattroPro10 does not share the problem (which I did not realize before). On checking, it seems apparent that this is because QPro does not use the common printing component (PrintServer10.exe and associated dlls); probably it was too much trouble to adapt QPro to the common printing system because of its distinctive code base. WordPerfect10 obviously does use it, as does Presentations10, the CorelCentral Addressbook, and other stuff. Probably Paradox does not, but I haven't checked it. Thus, the problem is correctly identified as an interaction difficulty between Mozilla and the WordPerfect Office2002/10 common printing system; it is just that not quite all components of WP10 Office use that common printing system. ......Robert Max Jackson
Does anyone have both WP2002 and DDESpy (comes with VC++)?
*** Bug 127906 has been marked as a duplicate of this bug. ***
In response to Dean Tessman's question of 2002-02-10: "I do!". I stumbled upon this bug after installing WP Office 2002 a few days ago. (Running on Win 2K and Mozilla build 2002030103). The symptoms are the same as those described, with one extra point of interest. I have several profiles configured in Mozilla. If quick launch is enabled but I have not yest selected a profile, printing a WordPerfect doc results in the profile manager being launched. Click 'Cancel' and it is relaunched. After 8-15 'cancels', the document is finally printed. I tried monitoring DDE activity with DDESpy, but observed nothing. The Spy++ message/process monitor provided some interesting info, though .. and maybe a few clues. I'm attaching a log of messages processed by Mozilla during the following sequence: - Mozilla running in task bar, no profile selected, no other mozilla windows open. - WP document open, ready to print - Start log (logging selected messages received by the Mozilla thread and its children) - click print in WordPerfect - observe document being prepared for printing and then observe Mozilla profile manager window being launched. - Close log It appears that both Mozilla and WP use the RegisterWindowMessage API for communicating between applications. (I'm not familiar with the details but the MS docs says its an alternative to DDE). You can see that Mozilla is indeed receiving and responding to messages from the WP print engine. I don't know enough about the inner working of Mozilla, but I'm guessing these messages are triggering the browser to launch. Hopefully this is of use to someone, and if there is any more information I can provide, let me know.
Keywords: qawanted
QA Contact: sairuh → tpreston
One of the bugaboos about using RegisterWindowMessage() is the following: "If two different applications register the same message string, the applications return the same message value." As a result, many people recommend appending a GUID value onto your message id string (passed to RegisterWindowMessage()) to try and ensure uniquenes of the ensuing message id value. Ouch...It doesn't look like Mozilla source is doing much to ensure uniqueness of these strings... if not, this may cause other problems with other apps in the future!
Would it be a large amount of work to append the GUID values? Would there a performance hit?
There is no performance hit at runtime. The way the api call works is you pass a "unique message string" to the RegisterWindowMessage function to generate a unique (system-wide) message id. The prototype is: UINT RegisterWindowMessage( LPCTSTR lpString ); It returns the message id as a UINT. For example, in order to prevent name clashes in the global application space we would construct a unique message string such as: "MyMessage_0745A558-F2A4-4255-8B10-E5E17D1DCC90" instead of just "MyMessage" and pass this to the RegisterWindowMessage() function in the source code.
Keywords: nsbeta1
Doing a search on the 0.9.8 source base, I find the following 8 calls to register a windows message (excluding any test modules). I don't know enough about the workings of mozilla to know whether any of the corresponding message handlers is involved in creating windows (and hence cause this problem) when WP is printing. If it is one of these, it is not obvious. \widget\src\windows\nsWindow.cpp(625): nsWindow::uWM_MSIME_RECONVERT = ::RegisterWindowMessage(RWM_RECONVERT); \widget\src\windows\nsWindow.cpp(628): nsWindow::uWM_ATOK_RECONVERT = ::RegisterWindowMessage(MSGNAME_ATOK_RECONVERT); \widget\src\windows\nsWindow.cpp(631): nsWindow::uWM_MSIME_MOUSE = ::RegisterWindowMessage(RWM_MOUSE); \widget\src\windows\nsWindow.cpp(638): nsWindow::uMSH_MOUSEWHEEL = RegisterWindowMessage(MSH_MOUSEWHEEL); \widget\src\windows\nsWindow.cpp(3827): UINT uiMsh_MsgScrollLines = RegisterWindowMessage(MSH_SCROLL_LINES); \xpcom\threads\plevent.c(1123): _pr_PostEventMsgId = RegisterWindowMessage("XPCOM_PostEvent"); \xpcom\typelib\xpidl\glib\glib-1.2.1\giowin32.c(733): g_pipe_readable_msg = RegisterWindowMessage ("g-pipe-readable"); \xpcom\typelib\xpidl\glib\glib-1.2.1\gutils.c(722): message = RegisterWindowMessage ("gdk-pipe-readable");
nsbeta1+ per Nav triage team, ->1.0
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.2 → mozilla1.0
Using the Visual C++ debugger I've been able to track down the source of this behavior. When you print with WP2002, the WP print process broadcasts status messages. These are listed in the message dump I posted earlier as: message:0xC197 [Registered:"Print engine, Server Job Status Message"] These messages are broadcast to all top level windows. All the mozilla top level windows return with a lResult of 0 except one. This window is of class "MozillaMessageWindow" and is created in the source file xpfe\bootstrap\nsNativeAppSupportWin.cpp, line 764. The function defined to process messages for this window is also in this file at line 808 (static long CALLBACK WindowProc( HWND msgWindow, UINT msg, WPARAM wp, LPARAM lp )). This function returns "TRUE", even for messages it doesn't handle. Just speculating here, but I'm guessing WordPerfect interprets the TRUE as a sign that this window can receive printer status information. WordPerfect then sends a WM_COPYDATA message along with a pointer to a data packet of printer status information. The same WindowProc *does* process this message, and if you follow the execution path through the call to nsNativeAppSupportWin::HandleRequest( (LPBYTE)cds->lpData ), the profile manager or a new moz window is launched.
Instead of WindowProc() returning TRUE, shouldn't it be: return DefWindowProc(msgWindow, msg, wp, lp); ?
WindowProc() and its "return TRUE" were added to nsNativeAppSupportWin in the fix for bug 53952. cc: Law, who wrote that proc originally. Bill, any reason why nsNativeAppSupportWin::WindowProc() explicitly returns TRUE?
Argh, sorry for the spam! Removing Law from the cc: list, since this bug is assigned to him.
I probably wanted it to return TRUE for something and at the time it wasn't envisioned that it would be called for anything except our own WM_COPYDATA purposes. Probably we should change that to "return DefWindowProc(...)." But maybe insert a "return TRUE" in the WM_USER case, too, to ensure we don't change anything that's going on there. I'll code up the patch and try to install the WP code to test it out (not sure how much of a hassle that will be).
As soon as the patch/fix is available in a build, some of us WordPerfect devotees will gladly test thouroughly if this eliminates the WP printing incompatibility problem. So, please let us know when it the patch does get incorporated.
Sounds like that may have been what you were thinking, Bill... WM_COPYDATA If the receiving application processes this message, it should return TRUE; otherwise, it should return FALSE. I can test this patch tonight in my build. I went through the trouble of installing the WP2002 trial edition a little while back.
Comment on attachment 73733 [details] [diff] [review] Patch, not tested yet with WP We should also be returning 0 for WM_LBUTTONDBLCLK. It probably doesn't matter too much with the current code, because it just returns TRUE (which is wrong for WM_LBUTTONDBLCLK), but with this patch it will fall through to DefWindowProc.
Wow, I'm just spamming this bug like crazy today! Ignore that last comment, I didn't see that WM_LBUTTONDBLCLICK was inside WM_USER. I think that we should probably return TRUE only inside the WM_RBUTTONUP and WM_LBUTTONDBLCLICK portions of WM_USER, and FALSE otherwise. This will help avoid situations similar to this in the future. WM_USER also isn't the best message. I filed bug 130361 to change it.
This patch does exactly that. Only if WM_USER is processed is TRUE returned, otherwise FALSE is returned in response to WM_USER. The standard return for WindowProc() is now DefWindowProc(). I tested this using the WP2002 trial. Last week when I tried it, it opened windows until I killed Moz. Tonight it didn't open any additional windows, and it printed the document without problems. I also tested the turbo tray icon, and everything still works off of there. The majority of this patch is whitespace clean-up, because things were a little messy inside WindowProc.
Attached patch cvs diff -uw (obsolete) — — Splinter Review
diff with whitespace changes ignored
ADT3 per ADT triage team
Whiteboard: [ADT3]
Bill, what do you think of my patch vs. yours? Either one will solve this problem.
I think I like mine better, for two reasons: 1. It is much smaller (even compared to your -w version). 2. It doesn't change anything for WM_USER messages that have lp values other than WM_RBUTTONDOWN or WM_LBUTTONDBLCLK. This of course ignores the fact that your patch fixes what are truly indentation problems and 2. might be technically more correct done your way. But that "ADT3" is ominous and we need to maximize the chance of pushing this through. We (I, at least) don't have license to fix indentation errors or to "fix" code that is broken only in theory. So now we just need r/sr/a.
Comment on attachment 73733 [details] [diff] [review] Patch, not tested yet with WP I'll buy that. r=me
Attachment #73733 - Flags: review+
Filed bug 131346 for cleaning up the indentation in this file.
Attachment #73828 - Attachment is obsolete: true
Attachment #73829 - Attachment is obsolete: true
build 2002031303 on windows nt4: No new mozilla windows are spawned when printing from Wordperfect, however printing has become terribly slow..really really slow. When killing mozilla, printing speeds up drastically. So the good news is in my case is that at least the computer doesn't crash anymore, but the bad news is that there still seems to be some unwanted interaction between wp2002 (sp2) and mozilla. Anyone else seeing this?
I don't see any noticeable slowdown here. Made a build with the patch from sources pulled today (Mar. 20) and printed a medium-sized doc (13 pages, full of graphics). Selected "Print to file" in WP (to save trees) and timed the process both with and withoug mozilla running. In both cases it took between 10 and 15 seconds on my box for printing to complete.
just to make sure : you patched your build yourself? Hmm... i just used a regular nightly build. That's interesting! I guess the patch for this hasn't been checked in and distributed with the nightlies in the first place, or has it? If it's not in the build then another bug fix also seems to be involved here...
Yes, I patched the sources myself. The nightly builds would not have this patch yet.
now that IS interesting. I just tested : on my current machine (XP pro, moz build 2002032003) indeed Mozilla spawns many windows when printing. That makes me wonder what happend on my NT4 machine with that specific build. will test nt4 machine tomorrow
So this is still a problem, then. This patch needs some sr-lovin'. Who can do that?
Comment on attachment 73733 [details] [diff] [review] Patch, not tested yet with WP sr=jag I'll buy this. Can someone back up either claim that Mozilla (with this fix) does or doesn't slow down printing under WP? If it does, I guess that's a new bug, is it something we can easily address?
Attachment #73733 - Flags: superreview+
Well, as a "knowledgeable user", but one with no involvement in mozilla development (and no programming in many years), I find the recent messages confusing. As of build 2002032003, the problematic interaction with WordPerfect still exists. As far as I can tell, however, the patch developed by Law & Tessman has not been entered into the nightly builds yet (is that correct?). So, I think that the recent problem reporting merely reflects this. When the patch is accepted and joins the builds, it gets posted on this bug tree, correct?
Jag, comment 102 says Mozilla (*with* the patch) does not impact printing performance of WordPerfect. Reports of slowdowns and multiple-window spawning are all cases where Mozilla is not patched. I'll request approval to check this in today.
Thank you very much for the work put into solving this bug.
Attachment #73733 - Flags: approval+
Comment on attachment 73733 [details] [diff] [review] Patch, not tested yet with WP a=asa (on behalf of drivers) for checkin to the 1.0 trunk
fixed
Fixed as of Win32 Nightly Build 2002032503. Verify me.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Confirm bug fixed when printing under WinNTSP6 & Win2000SP2 using WP10SP2 to local printer, over network, publish to PDF, and print to Adobe distiller. (phew, & immense thanks to those who did it) robert.jackson@nyu.edu
*** Bug 135130 has been marked as a duplicate of this bug. ***
verifying based on robert's comments
Status: RESOLVED → VERIFIED
I'm removing this release note item for this bug from the Mozilla 1.0 and future versions of the release notes because this bug is marked fixed. Mail me if you think this item should be re-added.
*** Bug 137988 has been marked as a duplicate of this bug. ***
*** Bug 117401 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: