From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; 0.7) Gecko/20010105 BuildID: 2001010517 Pasting an extremely long URL into the Navigation Toolbar causes a segmentation fault. Reproducible: Always Steps to Reproduce: 1. Start Navigator 2. Make sure there is text in the URL box 3. Highlight the contents of the URL box, and copy them to the clipboard. 4. Paste five times, creating a string five times as long as what you originally had. 5. Goto 3 until Mozilla crashes. Shouldn't take more than ten repeats. Actual Results: /usr/local/mozilla/run-mozilla.sh: line 72: 7434 Segmentation fault $prog ${1+"$@"} Expected Results: Mozilla should have thrown away any text beyond the size of memory allocated for the URL, and possibly have displayed a popup window notifying the user of this.

Just confirmed that this is still an issue in the current nightly (2001011708)

confirming using 2001.01.18.08 linux comm bits. stack trace from talkback is below. don't think this belongs in xp apps --perhaps either selection or event handling...? Incident ID 24859863 Trigger Time 2001-01-18 13:50:38 Email Address sairuh@netscape.com User Comments bug 65869 Build ID 2001011808 Product ID Netscape6 Platform ID LinuxIntel Stack Trace do_AssignFromReadable() do_AssignFromElementPtrLength() nsString::nsString() nsClipboard::SelectionGetCB() libgtk-1.2.so.0 + 0x8dffd (0x40553ffd) libgtk-1.2.so.0 + 0xbb5fd (0x405815fd) libgtk-1.2.so.0 + 0xbaa42 (0x40580a42) libgtk-1.2.so.0 + 0xb8eb9 (0x4057eeb9) libgtk-1.2.so.0 + 0xb7f58 (0x4057df58) libgtk-1.2.so.0 + 0xb70d3 (0x4057d0d3) nsClipboard::DoRealConvert() nsClipboard::DoConvert() nsClipboard::GetNativeClipboardData() nsClipboard::GetData() nsHTMLEditor::Paste() nsHTMLEditorLog::Paste() nsTextEditorMouseListener::MouseClick() nsEventListenerManager::HandleEvent() nsGenericElement::HandleDOMEvent() nsHTMLInputElement::HandleDOMEvent() nsGenericElement::HandleDOMEvent() nsGenericDOMDataNode::HandleDOMEvent() nsTextNode::HandleDOMEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsViewManager2::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x174db (0x405fd4db) libglib-1.2.so.0 + 0x10186 (0x4062a186) libglib-1.2.so.0 + 0x10751 (0x4062a751) libglib-1.2.so.0 + 0x108f1 (0x4062a8f1) libgtk-1.2.so.0 + 0x8c5b9 (0x405525b9) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x4023e9cb)

Adding Pavlov and Pinkerton since the stack trace looks like it's in gtk nsClipboard code.

This used to happen on Windows (bug 32334), but that bug morphed into a dup of another bug while I wasn't paying attention and is now wfm (I now hit bug 35229 instead).

handing this over to pav for a look

interesting, i no longer see this, using a debug build on linux [noon, today]. adam, is this still a problem for you, or could this be marked wfm?

I hope this bug hasn't been forgotten, since it is alive and well in moz0.9. I'd really hate to see a bug this simple not fixed pre-1.0, it's disturbing how easy it is for someone to crash mozilla.

Still a problem on linux on 2001102910 (yeseterday's nightly)

wfm using build 2001103113 on Linux with the following URL: http://www.sun.com/smi/Press/sunflash/2001-10/sunflashress/sunflash/2001-10/ress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflress/sunflash/2001-10/sunflash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20ash.20sunflash.20.20011024.1.html

pav who should get this?

wfm using Jan 28 2002 build on linux

changing selection qa to tpreston.

this has always wfm, and since everyone else says it wfm too, i'm marking this wfm