135699 - control click open in new tab crashes - Trunk [@ nsViewManager::GetViewObserver]

Status: VERIFIED DUPLICATE of bug 134664

(SeaMonkey :: Tabbed Browser, defect)

Description

[Don J. Rude]

Build: trunk nightly 2002040310 full installer
agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020403
Using CTRL+CLICK on a link to open in a new tab occaisonally crashes the
browser. Although I initially thought this was bug 134664 or even bug 134692 I
am able to get a crash without switching back to a previous tab OR even opening
a menu. I have several crashes where I ctrl+click and while waiting for the page
to finish loading and rendering, crashes.

I did a full uninstall of my previous builds before installing, although I am
using the same profile. I have "hide the tab bar" preference turned ON. I am
also using the classic theme.

Crash data:
TB4858511G - Crashed AFTER tab loaded and I was using CTRL+W to close the tab.
TB4858450H - Crashed after new tab loaded but during/after render
TB4858410W - Crashed after new tab loaded but during/after render

Comment 1

[Andrew Schultz]

the first one *might* be 134664, so let's focus on the last two.  Does this
occur at all URL's or only some (if only some, please report one)?   If you
"open in new window" or just left click on the link is everything ok?

Comment 2

[Don J. Rude]

Ok good news, I seem to have a working test case:
1. Start Mozilla (fresh)
2. Visit http://www.mozilla.org/projects/bugzilla/
  I have this bookmarked, but the case seems to work even if pasting the URL.
3. Press and hold the Control key while clicking on the "What is Bugzilla?" link.
4. KEEP HOLDING that control key until the page loads.

I also saw this when ctrl-clicking http://www.userfriendly.org/static/ but it
didn't seem to happen as consistently... I was also experimenting with releasing
the control key (it's an event after all) while the load was still in process.

These two are from the bugzilla page: TB4861962G AND TB4861936Q

It seems that right click "open in new tab" is always safe if you avoid the CTRL
key. In fact I can tap CTL while the page is loading from a right-click and
crash the browser. ( TB4862205M )

And yes a regular left click is fine.

Comment 3

[Jay Patel [:jay]]

Here are a couple of Don's incidents:

 Incident ID 4862205   
Stack Signature  nsViewManager::GetViewObserver 8f0a2769
Trigger Time 2002-04-05 09:15:34
Email Address [e-mail]
URL visited http://www.mozilla.org/projects/bugzilla/
Build ID 2002040310
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments tab ctrl
Stack Trace
nsViewManager::GetViewObserver
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2770]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2012]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1875]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchKeyEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2659]
nsWindow::OnKeyDown
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2697]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3539] 

 Incident ID 4861962   
Stack Signature  0x027177cf 6d25b8f9
Trigger Time 2002-04-05 09:09:24
Email Address [e-mail]
URL visited http://www.mozilla.org/projects/bugzilla/
Build ID 2002040310
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments hold control
Stack Trace
0x027177cf
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1875]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchKeyEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2659]
nsWindow::OnKeyDown
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2697]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3539]
0x027148b0 

Looking at the stacks...I do think this is a dup of 134664.  I'll leave it up to
the owner to decide whether to keep this open as a separate bug or mark it a dup.

Comment 4

[Jay Patel [:jay]]

I think bug 134957 might also be a dup candidate...take a look there for more
Talkback data.

Comment 5

[lchiang]

there is a testcase reported in the comments.  removing qawanted.
Nominate nsbeta1 since opening a new tab is pretty common.

Comment 6

[sairuh (rarely reading bugmail)]

hrm, so far i cannot quite repro this crash following the testcase in comment 2.
(using 2002.04.03.14 comm bits on linux rh7.2.) the one time i did crash, i had
to ctrl-click another link in the 2nd tab (to open a 3rd one) --but the trace
ended up identical to the ones in bug 134664. :-/ unless this might be limited
to win32...?

Comment 7

[Andrew Schultz]

I'm beginning to think bug 134664 has different behaviors for different OS's as
I am also unable to reproduce this or bug 135366.

Don: do you have any earlier builds (around 20020328)?  If you do, could you
check them to see if they exhibit this bug?  bug 134664 started happening then.

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Variance in the top of the stack trace can probably be explained by trying to
execute code at some random point in memory.  If it doesn't immediately crash,
it can obscure the top few stack frames (or the whole stack, sometimes, I'd think).

*** This bug has been marked as a duplicate of 134664 ***

Comment 9

[Martin Macok]

*** Bug 136762 has been marked as a duplicate of this bug. ***

Comment 10

[sairuh (rarely reading bugmail)]

marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica