bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
Printing seems to be broken in my 09/28/01 Debug Mozilla Trunk Build. Every time I press the OK button on the print dialog to start printing ... I get a "Failure" dialog. It seems that the call to StartDoc() in nsDeviceContextWin::BeginDocument() (nsDeviceContextWin.cpp line 756) fails and short circuits the printing process.
Reassigning to Rod.
Assignee: dcone → rods
no problem printing on linux, but it's another dialog as far as I know.
Cc'ing firstname.lastname@example.org ... rbs any chance this could've been caused by your landing yesterday?
Has anyone traced the source of the failure result?
I just pulled and built the trunk on WINNT and it prints fine.
Attinasi has a trunk build from this morning on WIN2K and it fails for him. His build should be about the same as my trunk build on WINNT. Looks like its WIN2K specific.
As I said above, nsDeviceContextWin::BeginDocument() is calling ::StartDoc(), which is failing with a -1 value which then gets mapped to an NS_ERROR_FAILURE. I added the following call after ::StartDoc(): DWORD err = ::GetLastError(); to retrieve the OS Error, and it returns err == 6 (ERROR_INVALID_HANDLE)
I would guess the mDC (printer device handle) must be bad. Either it was never allocated in the first place or it was released.
WFM on win98 using 9/28 build. must be win2K specific.
Not sure if this is related or not ... I put a call to GetLastError() after the call to CreateDC() in nsDeviceContextWin::GetDeviceContextFor(), and it returns a 50 (ERROR_NOT_SUPPORTED (The network request is not supported.)). Here's what's being passed into CreateDC() in my case: drivername == "winspool" devicename == "Print to File (HP LaserJet 5 PostScript)" Does that mean the DC it returns isn't valid or a type we expect?
Puzzling that it works on some systems and doesn't work on some. My checkins didn't involve nsDeviceContextWin per se. Maybe another problem was exposed. Here are links to the win32-specific parts of my checkins if they can be of any clue: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/gfx/src/windows&command=DIFF_FRAMESET&file=nsFontMetricsWin.cpp&rev1=3.116&rev2=3.117&root=/cvsroot http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/gfx/src/windows&command=DIFF_FRAMESET&file=nsRenderingContextWin.cpp&rev1=3.134&rev2=3.135&root=/cvsroot
Could people seeing the problem try what kin did above, i.e., printf("error:%d\n", ::GetLastError()) - that might help to know if the problem can be isolated in that function.
This is me. Kevin's gut feeling was right and provided the helpful clue... Click on the first link, and look at the second match of Find of: ::ReleaseDC(win, mDeviceContext->mDC ? dc : dc1) See how the logic is twisted!! Will attach the fix shortly.
Assignee: rods → rbs
I think renaming the two dc might be helpful, also put a comment in front of this call explaining why you are doing the check and what exactly failure means: nsFontWin* font = FindFont(dc1, 'a'); r=rods
Yup the patch allows printing again in my build. email@example.com after addressing rod's comments.
> nsFontWin* font = FindFont(dc1, 'a'); In fact, I don't think the check for a non-null |font| is even worth it. Failure never happens and in the even of failure (i.e., if there is no font at all to represent the simple letter 'a') the program cannot work, a crash will happen sooner or later.
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 102586 has been marked as a duplicate of this bug. ***
Summary: Can't print with today's 09/28/01 Mozilla Trunk Build. → Can't print on Win2K with today's 09/28/01 Mozilla Trunk Build.
*** Bug 102604 has been marked as a duplicate of this bug. ***
*** Bug 102605 has been marked as a duplicate of this bug. ***
not Win2K specific....removing from subject
Summary: Can't print on Win2K with today's 09/28/01 Mozilla Trunk Build. → Can't print with today's 09/28/01 Mozilla Trunk Build.
okay this should now be fixed in today's trunk builds. Can people on the cc: list who have Win2K please try it out and report back here in the bug report? thanks.
seems to be working for me now.
okay marking VERIFIED...REOPEN if any of you are still having problems printing with Win2K..thanks.
Status: RESOLVED → VERIFIED
*** Bug 103237 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.