Closed Bug 111897 Opened 23 years ago Closed 23 years ago

enter in an invalid url in the loc bar and poof

Categories

(SeaMonkey :: Location Bar, defect)

Product:
SeaMonkey
Component:
Location Bar
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 110560

People

(Reporter: squeakman2k1, Assigned: hewitt)

Details

i entered in something invalid in the location bar and mozilla
crashed.

here's how to reproduce:
1) load up a web page
2) enter 
      alert (window.frames[0].document.forms.length);
   in the location bar.
3) press enter.
4) watch mozilla segv :(

it was just javascript without the "javascript:" prefix.

here's something else interesting.
1) load up a web page
2) enter 
      alert (window.frames.length)
   in the location bar
3) mozilla will _not_ segv
4) mozilla will gracefully give host not found error

this is weird.
worksforme, linux build from 2001-11-24.  Reporter, what build are you using?
0.9.6
2001112217
http://bugzilla.gnome.org/show_bug.cgi?id=66532

http://www.darkhorse.com
(instant crash)

this is certainly a bug in 0.9.6
the darkhorse url reproducably crashes for me with 0.9.6 on RedHat 6,RedHat 7
and Windows  (libcookie.so and COOKIE.DLL)

and i couldnt find a duplicate
Do you have the flash plugin?  no crash here without flash...  crash with
flash.  Will test with a debug build once I'm not trying to run a debug build
with flash over remote X.....

Either way, I somehow doubt that's _this_ bug, which is about crashes on invalid
hostnames (which http://www.darkhorse.com is certainly not).
nope , no flash here

I would certainly move the bug to Cookies and Change the Summary line if i could 
:)

or maybe file a new one if you will, juts trying to keep the noise down

well... the darkhorse.com crash I see is a crash in the flash plugin itself... 
So it should not show up as being in libcookie.so.

In other words, I'm not seeing the crash you're seeing (linux 2001-12-08 build).
ok, so i tried with the latest trunk builds
mozilla-2001120817_trunk-0_rh7.i386.rpm
and mozilla-win32-installer-sea.exe

the bug is gone

but if i revert to 0.9.6 the bug is here again.
the only thing these two mozilla installa share is the same proxy and network
connection, but i dont think that matters at all, my rh6 does not use that proxy

so what do we do with this bug?:) i've asked other people to reproduce but
apparently they cant, the galeon bugreport shows otherwise (at least 3 closely
looking backtraces from different people)

If people can only reproduce it with 0.9.6 or 0.9.6-based galeon builds, we mark
it worksforme.  If people can reproduce it with galeon builds based on current
mozilla nightlys, we get a stack trace from one of those builds....
the only problem with this is that imho its not fair to stamp WORKSFORME on an
otherwise real bug (even if its fixed lately)

i've been testing mostly mozilla builds, dont think the embedding is an issue
with this bug

unfortunately i dont have the horespower to test with debug builds, the crash on
win is documented in a talckback i sent, donno where that goes tho, i've
mentioned that its a duplicate of this bug here
well.. the options are worksforme or duplicate if we find which checkin fixed
it.  :)

Could you run mozilla\Components\talkback.exe on your windows machine?  That
will give you a list of all the talkback incidents you have sent in.  Could you
find this one and post the talkback ID here?  That should let us at least get a
stack with symbols for it...
here is the talkback ID: TB229036Z
stephend, would you get the stack?  TB229036Z
Stack Signature  COOKIE_GetCookie 12baf355
Trigger Time 2001-12-08 19:21:13
Email Address yaneti@declera.com
URL visited http://www.darkhorse.com
User Comments this report is a duplicate of 111897 i am filling it just to show
that i am not hallucinating ;)
Build ID 2001112012
Product ID MozillaBranch
Platform
Operating System Win32
Module
Trigger Reason Access violation
Stack Trace
COOKIE_GetCookie [d:\builds\seamonkey\mozilla\extensions\cookie\nsCookies.cpp,
line 636]
COOKIE_GetCookieFromHttp
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookies.cpp, line 855]
nsCookieService::GetCookieStringFromHttp
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookieService.cpp, line 179]
nsCookieHTTPNotify::OnModifyRequest
[d:\builds\seamonkey\mozilla\extensions\cookie\nsCookieHTTPNotify.cpp, line 194]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 154]
nsProxyObject::Post
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEvent.cpp, line 430]
nsProxyEventObject::CallMethod
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 548]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsHttpHandler::OnModifyRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 583]
nsHttpChannel::Init
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 203]
nsHttpHandler::NewProxiedChannel
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, line 1669]
nsIOService::NewChannelFromURI
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 774]
imgLoader::LoadImage
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 203]
nsImageLoader::Load
[d:\builds\seamonkey\mozilla\layout\base\src\nsImageLoader.cpp, line 123]
nsPresContext::LoadImage
[d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 1417]
nsCSSRendering::PaintBackground
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSRendering.cpp, line 2269]
nsHTMLContainerFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLContainerFrame.cpp, line
101]
CanvasFrame::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 395]
PresShell::Paint
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5543]
nsView::Paint [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 275]
nsViewManager::RenderDisplayListElement
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1182]
nsViewManager::RenderViews
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1106]
nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp,
line 653]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1728]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 84]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 748]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 770]
nsWindow::OnPaint [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp,
line 4124]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3081]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1013]
KERNEL32.DLL + 0x3613 (0xbff63613)
KERNEL32.DLL + 0x248f7 (0xbff848f7) 
Yanko, you're seeing bug 110560 (fixed on trunk).  It's likely that this _would_
be triggered for random urls typed in the url bar as we checked for cookies for
those urls...

So this is probably a duplicate of bug 110560
thanks for tracking this Boris :)

now someone should RESOLVE DUPLICATE the bug i guess (i dont have the permission)
OK.  resolving.  If this problem reappears in 0.9.7- or nightly-based galeon,
please reopen....

*** This bug has been marked as a duplicate of 110560 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
mass-verifying Duplicate bugs which haven't changed since 2001.12.31.

set your search string in mail to "CitizenGKar" to filter out these messages.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.