82486 - potential buffer overruns handling user input in print dialog

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

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

DESCRIPTION:  There are a bunch of potential buffer overruns (that have been
copied across multiple gfx ports) in handling user input from the print dialog.

STEPS TO REPRODUCE:
 * File | Print
 * choose "File"
 * type a few hundred characters (just bang on your keyboard for a bit)

ACTUAL RESULTS:
 * crash

EXPECTED RESULTS:
 * no crash, maybe even an error message about the filename being too long, or
at least printing to the file with the name truncated.

ADDITIONAL INFORMATION:
The buffer overruns are discussed a bit in my review comments on bug 71587,
dated 2001-04-24 06:35.  They appear in various forms in at least the following
files:

gfx/src/beos/nsDeviceContextSpecB.cpp
gfx/src/gtk/nsDeviceContextSpecG.cpp
gfx/src/qt/nsDeviceContextSpecQT.cpp
gfx/src/xlib/nsDeviceContextSpecXlib.cpp

I didn't actually check that the cause of the crash was the buffer overruns I
mentioned.  Maybe it's others somewhere else.

Comment 1

[dcone (gone)]

This is a great one for future.

Comment 2

[dcone (gone)]

Is this a dialog issue.. not a printing issue

Comment 3

[Roland Mainz]

In theory we do not need to fix this as we need _urgendly_ a new print dialog.
Many people are not very amazed about it (ranging from "it s*cks" to "BTW -- I
find Mozilla's printing interface rather inadequate, compared to old Netscape,
which works fine with my Postscript NeXT_Printer" and so on...). 
We need a better one for unix/linux (to match the needs of PostScript/Xprint and
other platforms)... 
I'll fire-up a new bug for this in one or two days...

Comment 4

[dcone (gone)]

Seems this is a problem with the XUL dialog.. not printing. Assigning to the XUL 
guys who control this.

Comment 5

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

Ummm... the problems are at specific places in the code in the gfx directory
that I just pointed out above (and see the other bug I mention).  I wouldn't
call that a XUL bug.

Comment 6

[dcone (gone)]

You said that you type a few hundred characters into the print dialog, from 
looking at the code, this is all handled by the XUL code, the user input is not 
handled at all by the code you pointed to.  Unless its after you typed in the 
few hundred lines of code and that string is returned back to the printing code 
but I assumed that did not happen since the enter key, or ok key was not hit. 
From what I was told.. (I did not write the the printer dialogs for these 
platforms or GTK where this code was probably copied from) XUL handles this.. 
can you clarify (for someone like me who has no XUL experience) why this is not 
a XUL problem.  

Comment 7

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

I forgot to say that I had to hit enter.  However, it should have been obvious
from where I said the code with the buffer overrun was.

Comment 8

[dcone (gone)]

Taking back the bug.  

Comment 9

[Roland Mainz]

Taking bug...

Comment 10

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 11

[Roland Mainz]

This has been fixed now since a very long time.

Marking bug as FIXED.