102243 - Can't print with today's 09/28/01 Mozilla Trunk Build.

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[kinmoz]

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.

Comment 1

[sujay]

cc: twalker

Comment 2

[Kevin McCluskey (gone)]

Reassigning to Rod.

Comment 3

[Andreas Otte]

no problem printing on linux, but it's another dialog as far as I know.

Comment 4

[kinmoz]

Cc'ing [e-mail] ... rbs any chance this could've been caused by your 
landing yesterday?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Has anyone traced the source of the failure result?

Comment 6

[Kevin McCluskey (gone)]

I just pulled and built the trunk on WINNT and it prints fine.

Comment 7

[Kevin McCluskey (gone)]

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.

Comment 8

[kinmoz]

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)

Comment 9

[Kevin McCluskey (gone)]

I would guess the mDC (printer device handle) must be bad. Either it was never
allocated in the first place or it was released.

Comment 10

[sujay]

WFM on win98 using 9/28 build. must be win2K specific.

Comment 11

[kinmoz]

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?

Comment 12

[rbs]

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

Comment 13

[rbs]

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.

Comment 14

[rbs]

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.

Comment 15

[rbs]

Attachment: fix, ready for r/sr

Comment 16

[rods (gone)]

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

Comment 17

[kinmoz]

Yup the patch allows printing again in my build.

sr=[e-mail] after addressing rod's comments.

Comment 18

[rbs]

> 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.

Comment 19

[rbs]

Fix checked in.

Comment 20

[sujay]

*** Bug 102586 has been marked as a duplicate of this bug. ***

Comment 21

[sujay]

*** Bug 102604 has been marked as a duplicate of this bug. ***

Comment 22

[sujay]

*** Bug 102605 has been marked as a duplicate of this bug. ***

Comment 23

[sujay]

not Win2K specific....removing from subject

Comment 24

[sujay]

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.

Comment 25

[Scott MacGregor]

seems to be working for me now.

Comment 26

[sujay]

okay marking VERIFIED...REOPEN if any of you are still having problems
printing with Win2K..thanks.

Comment 27

[sujay]

*** Bug 103237 has been marked as a duplicate of this bug. ***