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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: tobias, Assigned: bryner)
References
()
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
686 bytes,
patch
|
bzbarsky
:
superreview+
asa
:
approval1.8b3+
|
Details | Diff | Splinter Review |
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)
Reporter | ||
Comment 1•19 years ago
|
||
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?
Updated•19 years ago
|
Blocks: blazinglyfastback
Comment 3•19 years ago
|
||
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 | ||
Comment 4•19 years ago
|
||
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)
Assignee | ||
Comment 5•19 years ago
|
||
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 6•19 years ago
|
||
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+
Assignee | ||
Comment 7•19 years ago
|
||
Comment on attachment 186442 [details] [diff] [review] patch requesting approval, low-risk crash fix
Attachment #186442 -
Flags: approval1.8b3?
Updated•19 years ago
|
Attachment #186442 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 8•19 years ago
|
||
Filed bug 297991 on the docviewer destroy cleanup. closing this as FIXED.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 9•19 years ago
|
||
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
Assignee | ||
Updated•18 years ago
|
Attachment #186442 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 10•18 years ago
|
||
Comment on attachment 186442 [details] [diff] [review] patch er, ignore that
Attachment #186442 -
Flags: review+
Updated•13 years ago
|
Crash Signature: [@ DocumentViewerImpl::Destroy]
You need to log in
before you can comment on or make changes to this bug.
Description
•