Henry Throop Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020318
BuildID:    2002031808

The above web page reliably crashes the browser, every time.  The page I've
listed is a copy from personals.salon.com, but it requires a login, so I've
copied the entire page over to my site.  However, printing any individual's
profile on this site causes the same crash.

Reproducible: Always
Steps to Reproduce:
1.Go to URL
2.Print to file, or printer
3.Moz crashes (browser, mail, etc.)

Actual Results:  Sometimes prints several 'NO FONT WAS FOUND' messages on
console before crashing.

TB ID's TB5275271M, TB5275100Q

Crashes on 2002031808 (nightly) and 2002031008 (0.9.9 release).  On a different
linux system, works on 2002020415.

	Vadim Berezniker
	Comment 1 • 23 years ago

I also had that problem with older builds but one day it just went away.

	Henry Throop Reporter
	Comment 2 • 23 years ago

Still crashes on me using the latest nightly (2002041609).  TB ID TB5278194Q.

	R.K.Aa.
	Comment 3 • 23 years ago

Sujay: Can you pull TB5278194Q ?

	sujay
	Comment 4 • 23 years ago

nsPostScriptObj::finalize_translation() 
nsPostScriptObj::~nsPostScriptObj() 
nsDeviceContextPS::~nsDeviceContextPS() 
DeviceContextImpl::Release() 
nsDeviceContextPS::Release() 
nsCOMPtr_base::~nsCOMPtr_base() 
nsDeviceContextGTK::GetDeviceContextFor() 
DocumentViewerImpl::Print() 
XPTC_InvokeByIndex() 
XPCWrappedNative::CallMethod() 
XPC_WN_CallMethod() 
js_Invoke() 
js_Interpret() 
js_Invoke() 
js_InternalInvoke() 
JS_CallFunctionValue() 
nsJSContext::CallEventHandler() 
nsJSEventListener::HandleEvent() 
nsEventListenerManager::HandleEventSubType() 
nsEventListenerManager::HandleEvent() 
nsXULElement::HandleDOMEvent() 
nsXULElement::HandleDOMEvent() 
nsXULElement::HandleDOMEvent() 
PresShell::HandleDOMEventWithTarget() 
nsButtonBoxFrame::MouseClicked() 
nsButtonBoxFrame::HandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEventWithTarget() 
nsEventStateManager::CheckForAndDispatchClick() 
nsEventStateManager::PostHandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsViewManager::HandleEvent() 
nsView::HandleEvent() 
nsViewManager::DispatchEvent() 
HandleEvent() 
nsWidget::DispatchEvent() 
nsWidget::DispatchWindowEvent() 
nsWidget::DispatchMouseEvent() 
nsWidget::OnButtonReleaseSignal() 
nsWindow::HandleGDKEvent() 
dispatch_superwin_event() 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x17e4f (0x40367e4f) 
libglib-1.2.so.0 + 0x117f3 (0x4039a7f3) 
libglib-1.2.so.0 + 0x11dd9 (0x4039add9) 
libglib-1.2.so.0 + 0x11f8c (0x4039af8c) 
libgtk-1.2.so.0 + 0x94803 (0x402af803) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x1c2ae (0x404e32ae) 

	Vadim Berezniker
	Comment 5 • 23 years ago

Sounds like bug 136053 (except that one is ONLY about printing to file)

When you're printing to the file, are you printing to a location that you can
write to?

	Henry Throop Reporter
	Comment 6 • 23 years ago

I don't think this has anything to do with print-to-file (or bug 136053).  I get
the same crash whether or not I send to a file or the printer.  And, I do have
proper permissions.

Two additional comments:

  o When it crashes, it does in fact generate a .ps file.  However, this file is
incomplete (44K vs. 1255K for a successful print) -- even though it does end
with %%EOF.  See attachments.

  o I've been able to print successfully w/o triggering the crash, if I have a
mail window open.  In some limited testing today, it would crash only if the
only window I had open was the browser.

	Henry Throop Reporter
	Comment 9 • 23 years ago

Still crashes on 1.0RC1 [2002041711].  The behavior has changed slightly, since
now there is a dialog that comes up, 'Printing failed for some reason.'  As soon
as 'OK' is hit, it'll crash and bring up talkback.  Again, some pages print OK,
but the URL given reliably fails.

Crashes on both RH 7.1 and 7.2 (two different machines).  1.0RC1 TB ID = TB5626573Z.

	Kai Lahmann (is there, where MNG is)
	Comment 10 • 22 years ago

still crash with 1.1beta?

	Benjamin Smedberg
	Comment 11 • 22 years ago

<throop@colorado.edu>: does this problem still occur in Mozilla 1.1 or recent
daily builds?

marking NEW

	Henry Throop Reporter
	Comment 12 • 22 years ago

Works for me in the Linux 1.1 release (20020826).

	Pete Zha
	Comment 13 • 22 years ago

mark WFM. If anybody can reproduce it, please feel free to reopen.

	sujay
	Comment 14 • 22 years ago

verified.