Closed
Bug 293403
Opened 20 years ago
Closed 20 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•20 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•20 years ago
|
Blocks: blazinglyfastback
Comment 3•20 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•20 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•20 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•20 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•20 years ago
|
||
Comment on attachment 186442 [details] [diff] [review]
patch
requesting approval, low-risk crash fix
Attachment #186442 -
Flags: approval1.8b3?
Updated•20 years ago
|
Attachment #186442 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 8•20 years ago
|
||
Filed bug 297991 on the docviewer destroy cleanup. closing this as FIXED.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 9•20 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•19 years ago
|
Attachment #186442 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 10•19 years ago
|
||
Comment on attachment 186442 [details] [diff] [review]
patch
er, ignore that
Attachment #186442 -
Flags: review+
Updated•14 years ago
|
Crash Signature: [@ DocumentViewerImpl::Destroy]
You need to log in
before you can comment on or make changes to this bug.
Description
•