16572 - Dogfood: With GFX Scroll bars on Mozilla crashes with 1-3 double clicks

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect, P2)

Description

[Alan S. Jones]

Win32 Build 10/15/99

If i turn GFX Scroll Bars on and then double click 1-3 times on the URL Bar to
highlight it Mozilla crashes.  The crash did not occure if GFX Scroll Bars were
off. Did not just happen to me, but to others.

I know you all have to priortize bugs, but found this was driving a few of us
crazy trying to test other things in Mozilla.  Everytime i would want to change
a URL i would double click and crash.


MOZILLA caused an invalid page fault in
module KERNEL32.DLL at 014f:bff9a29c.
Registers:
EAX=c0016f74 CS=014f EIP=bff9a29c EFLGS=00010216
EBX=0063fe28 SS=0157 ESP=0053fe24 EBP=005400c0
ECX=00000000 DS=0157 ESI=00760100 FS=1267
EDX=00540108 ES=0157 EDI=00000000 GS=0000
Bytes at CS:EIP:
53 8b 15 7c c2 fb bf 56 89 4d e4 57 89 4d dc 89
Stack dump:


== FROM DOS WINDOW EXTRA INFO ===============================
Successfully created instance of session history
Setting content window
browser.startup.page = 1
startpage = www.mozilla.org
adding "http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf" to
 the tree
http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf: setting po
ll interval to 300sec.
adding "rdf:msgnotifications" to the tree
adding "rdf:xpinstall-update-notifier" to the tree
got observer service
added observer
run LoadDetectorsMenu()
Document http://www.mozilla.org/ loaded successfully
Document: Done (11.1 secs)
flashReload(http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf
, 300)

===============================================

Comment 1

[Peter Trudelle]

reproduced on win98, in debug build from yesterday. reassigning to evaughan as
p2 for m11.
putting on dogfood radar.

Comment 2

[Claudius Gayle]

very much XP, easily repro'd on all platforms with the 19991020 opt builds

Comment 3

[Eric Vaughan]

Crashes in selection:
Are you taking into account the possibility of anonymous content? You can't make
the assumption that because a frame has 5 children is content node will have 5
children as well. The contents children could be anonymous.

nsDebug::PreCondition(const char * 0x01cee898
??_C@_0DJ@KMGL@You?5can?8t?5dereference?5a?5NULL?5nsC@, const char * 0x01cee8dc
??_C@_0N@NHHF@mRawPtr?5?$CB?$DN?50?$AA@, const char * 0x01cf0fc4
??_C@_0CB@MCGB@?4?4?2?4?4?2?4?4?2dist?2include?2nsCOMPtr?4h@, int 588) line 262
+ 13 bytes
nsCOMPtr<nsIContent>::operator->() line 588 + 34 bytes
nsContentIterator::GetNextSibling(nsCOMPtr<nsIContent> {...},
nsCOMPtr<nsIContent> * 0x0012f4d4) line 452 + 21 bytes
nsContentSubtreeIterator::Init(nsContentSubtreeIterator * const 0x034036a0,
nsIDOMRange * 0x034036f0) line 890 + 24 bytes
nsDOMSelection::selectFrames(nsDOMSelection * const 0x033d0b30, nsIDOMRange *
0x034036f0, int 1) line 1893
nsDOMSelection::Extend(nsDOMSelection * const 0x033d0b30, nsIDOMNode *
0x033e2e90, int -1) line 3037
nsTextFrame::HandleMultiplePress(nsTextFrame * const 0x03447120, nsIPresContext
& {...}, nsGUIEvent * 0x0012fbcc, nsEventStatus & nsEventStatus_eIgnore) line
2480 + 48 bytes
nsFrame::HandlePress(nsFrame * const 0x03447120, nsIPresContext & {...},
nsGUIEvent * 0x0012fbcc, nsEventStatus & nsEventStatus_eIgnore) line 795 + 27
bytes
nsFrame::HandleEvent(nsFrame * const 0x03447120, nsIPresContext & {...},
nsGUIEvent * 0x0012fbcc, nsEventStatus & nsEventStatus_eIgnore) line 772
PresShell::HandleEvent(PresShell * const 0x033d0c04, nsIView * 0x033e9920,
nsGUIEvent * 0x0012fbcc, nsEventStatus & nsEventStatus_eIgnore) line 2173 + 38
bytes
nsView::HandleEvent(nsView * const 0x033e9920, nsGUIEvent * 0x0012fbcc, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 834
nsView::HandleEvent(nsView * const 0x033e87d0, nsGUIEvent * 0x0012fbcc, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsView::HandleEvent(nsView * const 0x02dfb710, nsGUIEvent * 0x0012fbcc, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 819
nsViewManager::DispatchEvent(nsViewManager * const 0x02dfb890, nsGUIEvent *
0x0012fbcc, nsEventStatus & nsEventStatus_eIgnore) line 1739
HandleEvent(nsGUIEvent * 0x0012fbcc) line 63
nsWindow::DispatchEvent(nsWindow * const 0x033e8694, nsGUIEvent * 0x0012fbcc,
nsEventStatus & nsEventStatus_eIgnore) line 401 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fbcc) line 422
nsWindow::DispatchMouseEvent(unsigned int 324, nsPoint * 0x00000000) line 3394 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 324, nsPoint * 0x00000000) line
3612
nsWindow::ProcessMessage(unsigned int 515, unsigned int 1, long 393351, long *
0x0012fdf4) line 2630 + 24 bytes

Comment 4

[buster]

selection has it's own component.  assigning to mike

Comment 5

[mjudge]

this bug does not happen for other reasons than this exact crash. i have sent
another bug to joe allready about this.  This exact bug is fixed.

Comment 6

[Claudius Gayle]

VERIFIED fixed with 1999110808 builds

Comment 7

[rubydoo123]

linking to PDT+ tracking bug 12658