I've just checked in a patch to implement SVG events. In the process of testing them I've encountered a crash that seems unrelated. To reproduce this crash load the testcase and click on the small inner (zoom out) circle multiple times. gklayout.dll!nsFrame::PeekOffsetParagraph(nsPresContext * aPresContext=0x032cc490, nsPeekOffsetStruct * aPos=0x0012eee8) Line 3536 + 0x10 C++ gklayout.dll!nsFrame::PeekOffset(nsPresContext * aPresContext=0x032cc490, nsPeekOffsetStruct * aPos=0x0012eee8) Line 3846 + 0x17 C++ gklayout.dll!nsFrame::PeekBackwardAndForward(nsSelectionAmount aAmountBack=eSelectParagraph, nsSelectionAmount aAmountForward=eSelectParagraph, int aStartPos=3, nsPresContext * aPresContext=0x032cc490, int aJumpLines=1) Line 1649 + 0x1a C++ gklayout.dll!nsFrame::HandleMultiplePress(nsPresContext * aPresContext=0x032cc490, nsGUIEvent * aEvent=0x0012f5d4, nsEventStatus * aEventStatus=0x0012f33c) Line 1615 + 0x38 C++ gklayout.dll!nsFrame::HandlePress(nsPresContext * aPresContext=0x032cc490, nsGUIEvent * aEvent=0x0012f5d4, nsEventStatus * aEventStatus=0x0012f33c) Line 1357 + 0x1b C++ gklayout.dll!nsFrame::HandleEvent(nsPresContext * aPresContext=0x032cc490, nsGUIEvent * aEvent=0x0012f5d4, nsEventStatus * aEventStatus=0x0012f33c) Line 980 C++ gklayout.dll!PresShell::HandleEventInternal(nsEvent * aEvent=0x0012f5d4, nsIView * aView=0x03345ef0, unsigned int aFlags=1, nsEventStatus * aStatus=0x0012f33c) Line 6256 + 0x27 C++ gklayout.dll!PresShell::HandleEvent(nsIView * aView=0x03345ef0, nsGUIEvent * aEvent=0x0012f5d4, nsEventStatus * aEventStatus=0x0012f33c, int aForceHandle=0, int & aHandled=1) Line 6047 + 0x19 C++ gklayout.dll!nsViewManager::HandleEvent(nsView * aView=0x0334cf50, nsPoint aPoint={...}, nsGUIEvent * aEvent=0x0012f5d4, int aCaptured=0) Line 2553 C++ gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0012f5d4, nsEventStatus * aStatus=0x0012f4b0) Line 2245 + 0x22 C++ gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0012f5d4) Line 174 C++ gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012f5d4, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 1061 + 0xa C++ gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0012f5d4) Line 1082 C++ gkwidget.dll!nsWindow::DispatchMouseEvent(unsigned int aEventType=302, unsigned int wParam=1, nsPoint * aPoint=0x00000000) Line 5803 + 0x15 C++ gkwidget.dll!ChildWindow::DispatchMouseEvent(unsigned int aEventType=302, unsigned int wParam=1, nsPoint * aPoint=0x00000000) Line 6057 C++ gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=513, unsigned int wParam=1, long lParam=6815854, long * aRetValue=0x0012faa8) Line 4379 + 0x1c C++ gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00070746, unsigned int msg=513, unsigned int wParam=1, long lParam=6815854) Line 1243 + 0x1b C++

I should have mentioned that you will need to have pulled more recently than 2005-08-25 14:31 PST.

Taking, as this is in my code. I'll be able to look at it tomorrow.

This actually happens whenever you triple-click on a standalone SVG (i.e., one that is not embedded in HTML). Changing summary accordingly.

So basically, you can't assume that there will be a block on the parent frame chain.

Bail out if we reach the root element. I noticed that in these testcases the root element is a Viewport element, which does not have content associated with it. This is why I need the extra |if (aPos->mResultContent)|. In this case, a null content will be returned, and nothing useful will actually happen. I don't really know XUL, so I can't determine whether this actually breakes anything that should work. In the provided testcase, the text is non-selectable anyway, so nothing is broken. Can XUL text be selectable without being contained in a block frame? If so, can someone please provide a testcase?

Comment on attachment 194037 [details] [diff] [review] avoid crashes + reachedBlockAncestor = true; Use PR_TRUE. Thanks!

Changed "true" to PR_TRUE. Carrying over roc's review flags.

"regression" keyword, for the record.

Patch checked in by Simon Montagu, 2005-08-28 01:20. Thanks, Simon.

We'll want this fixed on the branch as well.

(In reply to comment #13) > We'll want this fixed on the branch as well. No, you won't, because this was never broken on the branch.