Closed Bug 71571 Opened 24 years ago Closed 23 years ago

embed crash @nsGfxScrollFrameInner::GetScrolledSize

Categories

(Core :: Layout, defect)

x86
Windows 98
defect
Not set
critical

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)

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()
Keywords: crash
OS: other → Windows 98
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
Reassigning to evaughan.
Assignee: karnaze → evaughan
Target Milestone: --- → mozilla0.9.1
Working on this one.
Status: NEW → ASSIGNED
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:
Attached patch Fix (deleted) — Splinter Review
Whiteboard: fixed, needs review
Attached patch Better patch (deleted) — Splinter Review
Severity: normal → critical
Less scary patch. No changes to view.
Attached patch Not view mods in this patch (deleted) — Splinter Review
patch 36438 looks good. r=kmcclusk@netscape.com
Whiteboard: fixed, needs review → wanted for 0.9.1 (fixed), patch has r= needs sr= and a=
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?
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.
> 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?
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.
ok, thanks for explaining that! :-) sr=waterson
Haven't seen this come through for checkin approval yet. Eric, is it ready?
yep it ready. Any time!
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=?
Any chance this is related to bug 77716?
I doubt it. Sounds like Hyatt knows whats happening on that bug.
Blocks: 83989
a=blizzard on behalf of drivers for the trunk.
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: