Closed Bug 293403 Opened 19 years ago Closed 19 years ago

crash when print page via Java-Script [@ DocumentViewerImpl::Destroy]

Categories

(Core :: Printing: Output, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: tobias, Assigned: bryner)

References

()

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050508 Mnenhy/0.7.2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050508 Mnenhy/0.7.2.0

Starting with tested Windows Nightly-Build 2005050506 Mozilla crashes when I try
to print page with JavaScript Print-Button from opend extra Window. 

Last known good Build was 2005050305, I have not tested 2005050405 because of
the regressions from bryners first Checkin for Bug 274784. 

Reproducible: Always

Steps to Reproduce:
1. Open URL:
http://www.meinestadt.de/saarbruecken/jobs?jobwrds=helfer&iwc=1&start=21&ob=-4
(other Pages from www.meinestadt.de/ (Categorie Jobs) will work too.
2. Click on one Link for an Job and let open another Window.
3. Click JS "drucken" link/or Printer Symbol, Mozilla Printer-Dialog open, and
click "O.k."-Button

Actual Results:  
After Clicking "O.k."-Button, Mozilla crashes, but printing was o.k.

Expected Results:  
Of course no crash, just print the Page. 

I have got some Problems to reproduce this Crash with different Profiles in a
good way. Have tested a lot Today and got very different Stacks. 

First I have used an Profile without mostly special Configurations, got this
Talkback-IDs:

TB5664402M, TB5663725Z, TB5663632X, TB5674680K 

and will add Stack Trace:

DocumentViewerImpl::Destroy 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsDocumentViewer.cpp,
line 1365]
DocumentViewerImpl::Show 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsDocumentViewer.cpp,
line 1669]
nsPresContext::EnsureVisible 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresContext.cpp,
line 1256]
PresShell::UnsuppressAndInvalidate 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5004]
PresShell::UnsuppressPainting 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5052]
PL_HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 699]
ntdll.dll + 0x30c24 (0x778b0c24)


Than I have tried to reproduce this with my normal Profile, there are some
modifications in the Prefs, especially I have set nearly all
dom.disable_window_open_feature.xxxx to "true" 
and second I have set the
user_pref("browser.sessionhistory.max_viewers", 5); like described in Bug 274784

This gave a lot of different Stacks, so this is probaly another Bug, but I dont
know. TB-Incidents: TB5665017Z, TB5664597G, TB5664559G, TB5664020M

And Stack-Trace from TB5664020M:

0x676e756c
nsSHEntry::~nsSHEntry 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/components/shistory/src/nsSHEntry.cpp,
line 100]



And last, irritating me I have  got some different Stacks with todays Build at 
js_AllocStack, TB-ID TB5674139E

and Stack: 

js_AllocStack 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 397]
nsXPCWrappedJSClass::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1133]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsContentTreeOwner::SetStatus 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,
line 381]
nsWebShell::OnOverLink 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp,
line 589]
nsGenericElement::TriggerLink 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 3366]
nsGenericHTMLElement::HandleDOMEventForAnchors 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1626]
nsHTMLAreaElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLAreaElement.cpp,
line 178]
nsEventStateManager::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2518]
nsEventStateManager::NotifyMouseOver 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2640]
nsEventStateManager::GenerateMouseEnterExit 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2672]
nsEventStateManager::PreHandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 479]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6317]
PresShell::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6163]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2502]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2224]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1180]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5906]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 6158]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1472]
USER32.dll + 0x2a3d0 (0x77e2a3d0)
USER32.dll + 0x4605 (0x77e04605)
USER32.dll + 0xa7ba (0x77e0a7ba)
nsAppStartup::Run 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/components/startup/src/nsAppStartup.cpp,
line 208]
main 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1763]
WinMain 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1787]
KERNEL32.DLL + 0x2893d (0x77e9893d)
Set Keywords Crash and Regression. CC'ing bryner because the first two types of
Stack-Traces are pointing to his checkins from 2005-05-04 13:22 for Bug 274784. 
Keywords: crash, regression
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050524
Firefox/1.0+ ID:2005052411

I can confirm this issue, but instead of crashing, it seems to make the browser
unusable, and when you close the browser the process still hangs.
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
we don't want 1.1a2 crash printing a form using javascript print()
It's not nice for a privateteer and real bad for business implementation.
Assignee: printing → bryner
Attached patch patchSplinter Review
This at least fixes the most serious problem I saw happening -- if Destroy()
was not called before the refcount goes to zero, the docviewer could hand out
an invalid reference to itself to its session history entry.  With this change
I no longer see the crash on this site (or some other odd behavior I was seeing
where we would stop processing plevents on the UI thread).

The whole Destroy() mechanism is a little shaky, especially with the print
special-casing, but I'm not sure what the best way is to clean it up.
Attachment #186442 - Flags: superreview?(bzbarsky)
Attachment #186442 - Flags: review?(bzbarsky)
Comment on attachment 186442 [details] [diff] [review]
patch

Spreading the love, in case Jonas can get to this sooner.  It's pretty
straightforward.
Attachment #186442 - Flags: review?(bzbarsky) → review?(bugmail)
Comment on attachment 186442 [details] [diff] [review]
patch

Please file a followup bug on clarifying and cleaning up the document viewer
ownership model?  We should try to fix that in 1.9, imo.
Attachment #186442 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 186442 [details] [diff] [review]
patch

requesting approval, low-risk crash fix
Attachment #186442 - Flags: approval1.8b3?
Attachment #186442 - Flags: approval1.8b3? → approval1.8b3+
Filed bug 297991 on the docviewer destroy cleanup. closing this as FIXED.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050628 on Windows XP Seamonkey trunk.
Status: RESOLVED → VERIFIED
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
Attachment #186442 - Flags: review?(bugmail) → review+
Comment on attachment 186442 [details] [diff] [review]
patch

er, ignore that
Attachment #186442 - Flags: review+
Crash Signature: [@ DocumentViewerImpl::Destroy]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: