Closed Bug 87788 Opened 23 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: thomas.swan, Assigned: law)

References

Details

(Keywords: dataloss, Whiteboard: [ADT3])

Attachments

(2 files, 2 obsolete files)

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: nsbeta1nsbeta1+
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: 22 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: