Closed
Bug 71571
Opened 24 years ago
Closed 23 years ago
embed crash @nsGfxScrollFrameInner::GetScrolledSize
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla0.9.1
People
(Reporter: bernd_mozilla, Assigned: eric)
References
Details
(Keywords: crash, Whiteboard: wanted for 0.9.1, patch; r=kmcclusk; sr=waterson; a=?)
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Win98 CVS 2001-03-09
steps to reproduce:
launch mfcembed, winembed or viewer.exe
select from your local harddisk layout/html/tests/table/interactive/bug7522.html
(you will not crash at lxr)
click on the link
crash
snippet:
nsIView* view;
frame->GetView(aPresContext, &view);
NS_ASSERTION(view,"Scrolled frame must have a view!!!");
nsRect rect(0,0,0,0);
view->GetBounds(rect);
stack trace
KERNEL32! bff768a0()
nsDebug::Assertion(const char * 0x02e1119c, const char * 0x02e11194, const char
* 0x02e1114c, int 1365) line 254 + 13 bytes
nsGfxScrollFrameInner::GetScrolledSize(const nsGfxScrollFrameInner * const
0x029d11e0, nsIPresContext * 0x02904160, int * 0x0069d86c, int * 0x0069d870)
line 1365 + 32 bytes
nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 1118
nsGfxScrollFrame::DoLayout(nsGfxScrollFrame * const 0x0091e1c8, nsBoxLayoutState
& {...}) line 1031 + 15 bytes
nsBox::Layout(nsBox * const 0x0091e1c8, nsBoxLayoutState & {...}) line 989
nsStackLayout::Layout(nsStackLayout * const 0x029d0150, nsIBox * 0x0091e138,
nsBoxLayoutState & {...}) line 256
nsContainerBox::DoLayout(nsContainerBox * const 0x0091e138, nsBoxLayoutState &
{...}) line 551 + 34 bytes
nsBoxFrame::DoLayout(nsBoxFrame * const 0x0091e138, nsBoxLayoutState & {...})
line 979
nsBox::Layout(nsBox * const 0x0091e138, nsBoxLayoutState & {...}) line 989
nsBoxFrame::Reflow(nsBoxFrame * const 0x0091e100, nsIPresContext * 0x02904160,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 781
nsRootBoxFrame::Reflow(nsRootBoxFrame * const 0x0091e100, nsIPresContext *
0x02904160, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 209
nsContainerFrame::ReflowChild(nsIFrame * 0x0091e100, nsIPresContext *
0x02904160, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 695 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x0091e0c4, nsIPresContext *
0x02904160, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 544
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x0316ee90,
nsIPresContext * 0x02904160, nsHTMLReflowMetrics & {...}, const nsSize & {...},
nsIRenderingContext & {...}) line 145
PresShell::ProcessReflowCommands(int 0) line 5169
PresShell::FlushPendingNotifications(PresShell * const 0x02f2bd60) line 4198
nsEventStateManager::FlushPendingEvents(nsIPresContext * 0x02904160) line 3236
nsEventStateManager::GenerateDragGesture(nsIPresContext * 0x02904160, nsGUIEvent
* 0x0069e4e0) line 779
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x029d1858,
nsIPresContext * 0x02904160, nsEvent * 0x0069e4e0, nsIFrame * 0x0091e238,
nsEventStatus * 0x0069e3d4, nsIView * 0x02f8e110) line 316
PresShell::HandleEventInternal(nsEvent * 0x0069e4e0, nsIView * 0x02f8e110,
unsigned int 1, nsEventStatus * 0x0069e3d4) line 4933 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x02f2bd64, nsIView * 0x02f8e110,
nsGUIEvent * 0x0069e4e0, nsEventStatus * 0x0069e3d4, int 0, int & 1) line 4874 +
25 bytes
nsView::HandleEvent(nsView * const 0x02f8e110, nsGUIEvent * 0x0069e4e0, unsigned
int 8, nsEventStatus * 0x0069e3d4, int 0, int & 1) line 372
nsView::HandleEvent(nsView * const 0x02f2e7d0, nsGUIEvent * 0x0069e4e0, unsigned
int 28, nsEventStatus * 0x0069e3d4, int 1, int & 1) line 345
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x02f2ebb0, nsGUIEvent *
0x0069e4e0, nsEventStatus * 0x0069e3d4) line 1424
HandleEvent(nsGUIEvent * 0x0069e4e0) line 68
nsWindow::DispatchEvent(nsWindow * const 0x02f8fee4, nsGUIEvent * 0x0069e4e0,
nsEventStatus & nsEventStatus_eIgnore) line 687 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0069e4e0) line 708
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3959 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 4169
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 2949149, long *
0x0069e898) line 2946 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00000edc, unsigned int 512, unsigned int 0, long
2949149) line 923 + 27 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()
I get a different assertion. The first time I run it I get "ASSERTION: Error
scroll port has too many children: 'count <=1', file
mozilla\view\src\nsScrollPortView.cpp, line 415". Loading it again displays the
contents of the interactive test directory.
Since it occurs in viewer.exe as well I am inclined to think it is a layout
issue so I'm reassigning.
Stack trace:
NTDLL! 77f9eea9()
nsDebug::Assertion(const char * 0x02b04f04, const char * 0x02b04ef8, const char
* 0x02b04ec0, int 0x0000019f) line 286 + 13 bytes
nsScrollPortView::SetScrolledView(nsScrollPortView * const 0x02c294a8, nsIView *
0x02d26e08) line 415 + 32 bytes
nsHTMLContainerFrame::CreateViewForFrame(nsIPresContext * 0x02b59cc0, nsIFrame *
0x02c16cbc, nsIStyleContext * 0x02d15060, nsIFrame * 0x00000000, int 0x00000001)
line 552
nsScrollBoxFrame::SetUpScrolledFrame(nsIPresContext * 0x02b59cc0) line 131 + 26
bytes
nsScrollBoxFrame::InsertFrames(nsScrollBoxFrame * const 0x02c16014,
nsIPresContext * 0x02b59cc0, nsIPresShell & {...}, nsIAtom * 0x00000000,
nsIFrame * 0x00000000, nsIFrame * 0x02c16cbc) line 180
FrameManager::InsertFrames(FrameManager * const 0x01042958, nsIPresContext *
0x02b59cc0, nsIPresShell & {...}, nsIFrame * 0x02c16014, nsIAtom * 0x00000000,
nsIFrame * 0x00000000, nsIFrame * 0x02c16cbc) line 824
nsCSSFrameConstructor::ReconstructDocElementHierarchy(nsCSSFrameConstructor *
const 0x0105e470, nsIPresContext * 0x02b59cc0) line 7294 + 66 bytes
StyleSetImpl::ReconstructDocElementHierarchy(StyleSetImpl * const 0x0105e270,
nsIPresContext * 0x02b59cc0) line 1233
PresShell::ReconstructFrames() line 4616 + 38 bytes
PresShell::StyleSheetAdded(PresShell * const 0x01047238, nsIDocument *
0x010fc750, nsIStyleSheet * 0x01053a60) line 4628
nsXULDocument::InsertStyleSheetAt(nsXULDocument * const 0x010fc750,
nsIStyleSheet * 0x01053a60, int 0x00000000, int 0x00000001) line 1296
CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x01053a60, int 0x00000002,
nsIContent * 0x00000000, int 0x00000001, nsICSSLoaderObserver * 0x00000000) line
1110
CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x01053a60, SheetLoadData *
0x02b5e3d0) line 813
CSSLoaderImpl::Cleanup(URLKey & {...}, SheetLoadData * 0x01059aa0) line 690
CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x00000000, SheetLoadData *
0x01059aa0) line 833
CSSLoaderImpl::Cleanup(URLKey & {...}, SheetLoadData * 0x02c47930) line 690
CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x00000000, SheetLoadData *
0x02c47930) line 833
CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x02c4f2d8, SheetLoadData *
0x02c47930, int & 0x00000001, nsICSSStyleSheet * & 0x02bc83c8) line 868
CSSLoaderImpl::DidLoadStyle(nsIStreamLoader * 0x02c47a48, nsString * 0x02c6a8a0,
SheetLoadData * 0x02c47930, unsigned int 0x00000000) line 903 + 27 bytes
SheetLoadData::OnStreamComplete(SheetLoadData * const 0x02c47930,
nsIStreamLoader * 0x02c47a48, nsISupports * 0x00000000, unsigned int 0x00000000,
unsigned int 0x00002243, const char * 0x02cfb000) line 643
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x02c47a4c, nsIRequest *
0x02c47f30, nsISupports * 0x00000000, unsigned int 0x00000000) line 120 + 81
bytes
nsJARChannel::OnStopRequest(nsJARChannel * const 0x02c47f34, nsIRequest *
0x00357244, nsISupports * 0x00000000, unsigned int 0x00000000) line 584 + 49
bytes
nsOnStopRequestEvent::HandleEvent() line 159
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02c9a8e4) line 64
PL_HandleEvent(PLEvent * 0x02c9a8e4) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e5d060) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002d0334, unsigned int 0x0000c114, unsigned int
0x00000000, long 0x00e5d060) line 1069 + 9 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
CWinThread::Run() line 480 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x00133d96, int 0x00000001) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133d96,
int 0x00000001) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e992a6()
Assignee: adamlock → karnaze
Component: Embedding APIs → Layout
QA Contact: mdunn → petersen
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 4•23 years ago
|
||
Have fix. Turns out that the code was just going up and getting the parent frame
when it really wanted the frame that contained the document. The view code was
also not removing views when frames were removed.
Patch attached:
Assignee | ||
Comment 5•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Whiteboard: fixed, needs review
Assignee | ||
Comment 6•23 years ago
|
||
Updated•23 years ago
|
Severity: normal → critical
Assignee | ||
Comment 7•23 years ago
|
||
Less scary patch. No changes to view.
Assignee | ||
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
patch 36438 looks good. r=kmcclusk@netscape.com
Updated•23 years ago
|
Whiteboard: fixed, needs review → wanted for 0.9.1 (fixed), patch has r= needs sr= and a=
Comment 10•23 years ago
|
||
With this change, why should we get the |docElementFrame| at all? It's never
used. Also, the |mDocelementContainingBlock| gets set up differently if we're
printing. Will this code work properly in that case?
Assignee | ||
Comment 11•23 years ago
|
||
This should work ok with printing because printing has not scroll frame. So
mDocElementContainingBlock will just be the parent container.
We need to get the docElementFrame just to see if we need to do all this work.
I'm assuming there are valid cases where a content node has no frame. This is
how the code was originally so I didn't want to change it.
Comment 12•23 years ago
|
||
> We need to get the docElementFrame just to see if we need to do all this
> work. I'm assuming there are valid cases where a content node has no frame.
> This is how the code was originally so I didn't want to change it.
But in that case, won't mDocElementContainingBlock be null, too? Or is it the
case that we leave mDocElementContainingBlock dangling at a destroyed frame some
place?
Assignee | ||
Comment 13•23 years ago
|
||
mDocElementContainingBlock should never be null. docElementFrame is inside
mDocElementContainingBlock. The way the code was originally written it assumed
the case where the content node's frame docElementFrame could be null. So I
didn't change the logic.
Comment 14•23 years ago
|
||
ok, thanks for explaining that! :-)
sr=waterson
Comment 15•23 years ago
|
||
Haven't seen this come through for checkin approval yet. Eric, is it ready?
Assignee | ||
Comment 16•23 years ago
|
||
yep it ready. Any time!
Updated•23 years ago
|
Whiteboard: wanted for 0.9.1 (fixed), patch has r= needs sr= and a= → wanted for 0.9.1, patch; r=kmcclusk; sr=waterson; a=?
Comment 17•23 years ago
|
||
Any chance this is related to bug 77716?
Assignee | ||
Comment 18•23 years ago
|
||
I doubt it. Sounds like Hyatt knows whats happening on that bug.
Comment 19•23 years ago
|
||
a=blizzard on behalf of drivers for the trunk.
Comment 20•23 years ago
|
||
looks like this is in on the branch.
we should mark it fixed so it gets tested. open another bug
for the trunk if there is more work to do there.
Assignee | ||
Comment 21•23 years ago
|
||
Fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•