Bug 74569 - [EL] [test case] submit confimation dialog appears twice, closing the second one crashes konqueror (javascript-related)
Summary: [EL] [test case] submit confimation dialog appears twice, closing the second ...
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: khtml forms (show other bugs)
Version: 3.2
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 75280 103141 104846 105899 123658 127125 128816 129389 131054 134018 137624 144852 156408 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-08 14:41 UTC by Rudo Thomas
Modified: 2012-06-18 17:43 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
this also crashes in HEAD (what will be 3.3) (412 bytes, text/html)
2004-07-26 23:34 UTC, Michael Jahn
Details
TC: Submits the form twice and crashed (1.02 KB, text/html)
2007-03-02 11:12 UTC, gmud
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rudo Thomas 2004-02-08 14:41:53 UTC
Version:           3.2.0 (using KDE 3.2 BRANCH >= 20040204, yes)
Compiler:          gcc version 3.3.2 20040108 (Gentoo Linux 3.3.2-r6, propolice-3.3-7)
OS:          Linux (i686) release 2.6.2

Some of the pages I visit use code like this:

<HTML><HEAD><TITLE>x</TITLE></HEAD>
<BODY>
 <FORM NAME="search" ACTION="action" METHOD="GET">
   <INPUT TYPE="text" SIZE=15
onKeyPress="if(event.which==13) {document.search.submit()}">
   <INPUT TYPE="submit" VALUE="BOOM">
 </FORM>
</BODY>
</HTML>

When you press Enter in the input field, two confirmation dialogs show up ("Warn on sending unencrypted data" must be turned on). The second one opens after the first one is closed by clicking "yes". When you try to close the second one (no matter whether you click on "yes" or "no" button), konqueror crashes. Happens in both 3.2.0 and 3.2 branch.

Konqueror's debug output shows nothing interesting (just KHTMLPart::submitForm appears twice in a row), here is the backtrace:

[Thread debugging using libthread_db enabled]
[New Thread 1092656992 (LWP 15471)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1092656992 (LWP 15471)]
0x419363e1 in KJS::ScopeChain::deref() (this=0x28) at scope_chain.h:63
	in scope_chain.h
#0  0x419363e1 in KJS::ScopeChain::deref() (this=0x28) at scope_chain.h:63
#1  0x41a7c9bc in KJS::ScopeChain::operator=(KJS::ScopeChain const&) (
    this=0x28, c=@0xbfffe3a0) at ../../kdelibs/kjs/scope_chain.cpp:41
#2  0x41936439 in KJS::ObjectImp::setScope(KJS::ScopeChain const&) (this=0x0, 
    s=@0xbfffe3a0) at object.h:570
#3  0x41933dc4 in KJS::Object::setScope(KJS::ScopeChain const&) (
    this=0x8207ebc, s=@0xbfffe3a0) at object.h:711
#4  0x4192c545 in KJS::JSEventListener::handleEvent(DOM::Event&) (
    this=0x8207eb0, evt=@0xbfffe460)
    at ../../../kdelibs/khtml/ecma/kjs_events.cpp:106
#5  0x417ec32b in DOM::NodeImpl::handleLocalEvents(DOM::EventImpl*, bool) (
    this=0x8260428, evt=0x828e380, useCapture=false)
    at ../../../kdelibs/khtml/xml/dom_nodeimpl.cpp:693
#6  0x417eb8dc in DOM::NodeImpl::dispatchGenericEvent(DOM::EventImpl*, int&) (
    this=0x8260428, evt=0x828e380)
    at ../../../kdelibs/khtml/xml/dom_nodeimpl.cpp:505
#7  0x417eb6af in DOM::NodeImpl::dispatchEvent(DOM::EventImpl*, int&, bool) (
    this=0x8260428, evt=0x828e380, exceptioncode=@0xbfffe558, tempEvent=true)
    at ../../../kdelibs/khtml/xml/dom_nodeimpl.cpp:469
#8  0x417ec21c in DOM::NodeImpl::dispatchKeyEvent(QKeyEvent*, bool) (
    this=0x8260428, key=0xbfffeb60, keypress=true)
    at ../../../kdelibs/khtml/xml/dom_nodeimpl.cpp:674
#9  0x41788a00 in KHTMLView::dispatchKeyEventHelper(QKeyEvent*, bool) (
    this=0x82363b0, _ke=0xbfffeb60, keypress=true)
    at ../../kdelibs/khtml/khtmlview.cpp:1008
#10 0x41788750 in KHTMLView::dispatchKeyEvent(QKeyEvent*) (this=0x82363b0, 
    _ke=0xbfffeb60) at ../../kdelibs/khtml/khtmlview.cpp:964
#11 0x41788b1a in KHTMLView::keyPressEvent(QKeyEvent*) (this=0x82363b0, 
    _ke=0xbfffeb60) at ../../kdelibs/khtml/khtmlview.cpp:1027
#12 0x41789d9b in KHTMLView::eventFilter(QObject*, QEvent*) (this=0x82363b0, 
    o=0x8272200, e=0xbfffeb60) at ../../kdelibs/khtml/khtmlview.cpp:1383
#13 0x40d6f561 in QObject::activate_filters(QEvent*) (this=0x8272200, 
    e=0xbfffeb60) at kernel/qobject.cpp:902
#14 0x40d6f3df in QObject::event(QEvent*) (this=0x8272200, e=0xbfffeb60)
    at kernel/qobject.cpp:735
#15 0x40da92f9 in QWidget::event(QEvent*) (this=0x8272200, e=0xbfffeb60)
    at kernel/qwidget.cpp:4408
#16 0x40e3e65a in QLineEdit::event(QEvent*) (this=0x8272200, e=0xbfffeb60)
    at widgets/qlineedit.cpp:1406
#17 0x418755de in khtml::LineEditWidget::event(QEvent*) (this=0x8272200, 
    e=0xbfffeb60) at ../../../kdelibs/khtml/rendering/render_form.cpp:395
#18 0x40d0ec73 in QApplication::internalNotify(QObject*, QEvent*) (
    this=0xbffff140, receiver=0x8272200, e=0xbfffeb60)
    at kernel/qapplication.cpp:2582
#19 0x40d0e303 in QApplication::notify(QObject*, QEvent*) (this=0xbffff140, 
    receiver=0x8272200, e=0xbfffeb60) at kernel/qapplication.cpp:2339
#20 0x408a3f29 in KApplication::notify(QObject*, QEvent*) (this=0xbffff140, 
    receiver=0x8272200, event=0xbfffeb60)
    at ../../kdelibs/kdecore/kapplication.cpp:506
#21 0x40ca3df6 in QApplication::sendSpontaneousEvent(QObject*, QEvent*) (
    receiver=0x8272200, event=0xbfffeb60) at qapplication.h:495
#22 0x40c9ec48 in QETWidget::translateKeyEvent(_XEvent const*, bool) (
    this=0x8272200, event=0xbfffeee0, grab=false)
    at kernel/qapplication_x11.cpp:5499
#23 0x40c9b361 in QApplication::x11ProcessEvent(_XEvent*) (this=0xbffff140, 
    event=0xbfffeee0) at kernel/qapplication_x11.cpp:3655
#24 0x40cb5453 in QEventLoop::processEvents(unsigned) (this=0x80c7248, flags=4)
    at kernel/qeventloop_x11.cpp:192
#25 0x40d24a31 in QEventLoop::enterLoop() (this=0x80c7248)
    at kernel/qeventloop.cpp:198
#26 0x40d2494a in QEventLoop::exec() (this=0x80c7248)
    at kernel/qeventloop.cpp:145
#27 0x40d0eddf in QApplication::exec() (this=0xbffff140)
    at kernel/qapplication.cpp:2705
#28 0x4005b5bf in kdemain (argc=2, argv=0xbffff2c4)
    at ../../kdebase/konqueror/konq_main.cc:184
#29 0x080486e6 in main (argc=2, argv=0xbffff2c4) at konqueror.la.cc:2

I hope this helps.

Have a nice day.

Rudo.
Comment 1 Michael Jahn 2004-07-26 23:34:16 UTC
Created attachment 6867 [details]
this also crashes in HEAD (what will be 3.3)

A valgrind trace / terminal output is at
http://www.affenschlaffe.de/kde-bugs/74569_valgrind.log
Comment 2 Michael Jahn 2004-07-26 23:36:58 UTC
Just to clarify: the attachment is the testcase which will probably crash your konquy.
Comment 3 Rudo Thomas 2004-07-27 00:39:41 UTC
It is worthwhile to mention that this problem has been fixed in 3.2.X, sort of.

It does not crash anymore, although the dialog still appears twice *and* the
form is submitted twice as well. (When you confirm the submit twice, that is.)

Rudo.

Comment 4 Michael Jahn 2004-08-03 17:46:08 UTC
Well, it does crash in 3.3x so if there is a fix for 3.2x it was only applied to that branch.
Comment 5 Rudo Thomas 2004-12-09 17:23:09 UTC
Still crashes in 3.3.1.!!!
Comment 6 Tommi Tervo 2005-05-24 12:32:36 UTC
3.4.1 still crashes. Had to repeat testcase twice until it crashed.

Program received signal SIGSEGV, Segmentation fault.
0x287527a2 in KLineEdit::keyPressEvent (this=0x8421100, e=0x85123e0)
    at klineedit.cpp:659
659                 d->disableRestoreSelection = false;
(gdb) bt
#0  0x287527a2 in KLineEdit::keyPressEvent (this=0x8421100, e=0x85123e0)
    at klineedit.cpp:659
#1  0x29bdc3e0 in khtml::RenderWidget::EventPropagator::sendEvent (
    this=0x8421100, e=0x85123e0) at render_replaced.cpp:669
#2  0x29bdc8ea in khtml::RenderWidget::handleEvent (this=0x83903c4,
    ev=@0x8624f00) at render_replaced.cpp:778
#3  0x29b7333f in DOM::HTMLGenericFormElementImpl::defaultEventHandler (
    this=0x82f7600, evt=0x8624f00) at html_formimpl.cpp:922
#4  0x29b77649 in DOM::HTMLInputElementImpl::defaultEventHandler (
    this=0x82f7600, evt=0x8624f00) at html_formimpl.cpp:1647
#5  0x29b2c38f in DOM::NodeImpl::dispatchGenericEvent (this=0x82f7600,
    evt=0x8624f00) at dom_nodeimpl.cpp:458
#6  0x29b2bee7 in DOM::NodeImpl::dispatchEvent (this=0x82f7600, evt=0x8624f00,
    exceptioncode=@0xbfbfee3c, tempEvent=true) at dom_nodeimpl.cpp:402
#7  0x29b2cea6 in DOM::NodeImpl::dispatchKeyEvent (this=0x82f7600,
    key=0xbfbff450, keypress=true) at dom_nodeimpl.cpp:633
#8  0x29ab42af in KHTMLView::dispatchKeyEventHelper (this=0x8346d00,
    _ke=0xbfbff450, keypress=true) at khtmlview.cpp:1326
#9  0x29ab3fb1 in KHTMLView::dispatchKeyEvent (this=0x8346d00, _ke=0xbfbff450)
    at khtmlview.cpp:1282
#10 0x29ab47f3 in KHTMLView::keyPressEvent (this=0x8346d00, _ke=0xbfbff450)
    at khtmlview.cpp:1405
#11 0x29ab693c in KHTMLView::eventFilter (this=0x8346d00, o=0x8421100,
    e=0xbfbff450) at khtmlview.cpp:1884
#12 0x28e6f9ee in QObject::activate_filters ()
   from /usr/X11R6/lib/libqt-mt.so.3
#13 0x28e6f89d in QObject::event () from /usr/X11R6/lib/libqt-mt.so.3
#14 0x28e9ead9 in QWidget::event () from /usr/X11R6/lib/libqt-mt.so.3
#15 0x28f1820a in QLineEdit::event () from /usr/X11R6/lib/libqt-mt.so.3
#16 0x29bdf430 in khtml::LineEditWidget::event (this=0x8421100, e=0xbfbff450)
    at render_form.cpp:403
#17 0x28e234d7 in QApplication::internalNotify ()
   from /usr/X11R6/lib/libqt-mt.so.3
#18 0x28e22935 in QApplication::notify () from /usr/X11R6/lib/libqt-mt.so.3
#19 0x289eeee4 in KApplication::notify (this=0xbfbffa48, receiver=0x8421100,
    event=0xbfbff450) at kapplication.cpp:549
#20 0x28dcaefc in QETWidget::translateKeyEvent ()
   from /usr/X11R6/lib/libqt-mt.so.3
#21 0x28dc6c2a in QApplication::x11ProcessEvent ()
   from /usr/X11R6/lib/libqt-mt.so.3
#22 0x28dda3e4 in QEventLoop::processEvents ()
   from /usr/X11R6/lib/libqt-mt.so.3
#23 0x28e32126 in QEventLoop::enterLoop () from /usr/X11R6/lib/libqt-mt.so.3
#24 0x28e3207b in QEventLoop::exec () from /usr/X11R6/lib/libqt-mt.so.3
#25 0x28e23646 in QApplication::exec () from /usr/X11R6/lib/libqt-mt.so.3
#26 0x280c18e2 in kdemain (argc=1, argv=0xbfbffb94) at konq_main.cc:206
Comment 7 Tommi Tervo 2005-05-24 12:34:18 UTC
*** Bug 75280 has been marked as a duplicate of this bug. ***
Comment 8 Pieter Botha 2005-08-14 16:10:41 UTC
Tested using the following code: 
<HTML><HEAD><TITLE>x</TITLE></HEAD> 
 <BODY> 
  <FORM NAME="search" ACTION="action" METHOD="GET"> 
    <INPUT TYPE="text" SIZE=15 
 onKeyPress="if(event.which==13) {document.search.submit()}"> 
    <INPUT TYPE="submit" VALUE="BOOM"> 
  </FORM> 
 </BODY> 
 </HTML> 


Warning of sending unencrypted data was turned on. Reponse was: 
An error occurred while loading file:///home/jackal/action:
The file or folder /home/jackal/action does not exist.
^^ Konqueror did not crash. 
Thus, bug is un-reproducible in Konqueror 3.4.2 Suse 9.3 x64 RPM on amd64.
Comment 9 Rudo Thomas 2005-08-14 16:50:08 UTC
> Warning of sending unencrypted data was turned on. Reponse was: 
> An error occurred while loading file:///home/jackal/action:
> The file or folder /home/jackal/action does not exist.
> ^^ Konqueror did not crash. 
> Thus, bug is un-reproducible in Konqueror 3.4.2 Suse 9.3 x64 RPM on amd64.


Did you press the enter key? For me, the confirmation dialog appears
again, after you confirm it the first time. When you confirm it for the
second time, konqueror crashes.

I am using gentoo; maybe the problem is patched in suse, who knows.

However, I cannot provide you with a back-trace right now.

Rudo.
Comment 10 Rudo Thomas 2005-08-14 16:52:54 UTC
Forgot to explicitly state that my box is an i386. Maybe it simply does
not happen on x64.

Rudo.
Comment 11 Iskren Stoyanov 2005-08-14 17:38:11 UTC
I'm using KDE 3.4.0-28 i586 on SuSE 9.3.Konqueror doesn't crash when "Warn on sending unencrypted data" is unchecked, but when warning is turned on konqueror crashes. 
Comment 12 Maksim Orlovich 2005-11-13 19:25:47 UTC
OK, here is the analysis of what happens:
1. You press enter.
2. The enter handler calls form submit, which pops up the question dialog, you press OK
3. the normal submit action thingie triggers (it's enter!) and pops up a question dialog
4. the question dialog enters a recursive event loop.
5. in the recursive event loop, we navigate away from the page, removing it
6. the user closes the dialog, and we attempt to keep working with the page..

Now, the two dialogs can probably be fixed by adding some sort of "page already being submitted" bit (I am not familiar with the code enough to do that, sorry).

The underlying issue of the crash, though, is the nested event loop for message boxes causing socket notifiers to be processed, same as bug #56118 (and possibly related to a whole bunch of other crashes, going through and analyzing the class atm)
Comment 13 Maksim Orlovich 2005-11-13 20:45:40 UTC
*** Bug 103141 has been marked as a duplicate of this bug. ***
Comment 14 Maksim Orlovich 2005-11-13 21:34:03 UTC
*** Bug 104846 has been marked as a duplicate of this bug. ***
Comment 15 Maksim Orlovich 2005-11-13 21:40:19 UTC
*** Bug 105899 has been marked as a duplicate of this bug. ***
Comment 16 Tommi Tervo 2006-03-15 13:55:56 UTC
*** Bug 123658 has been marked as a duplicate of this bug. ***
Comment 17 Tommi Tervo 2006-05-11 14:54:34 UTC
*** Bug 127125 has been marked as a duplicate of this bug. ***
Comment 18 Tommi Tervo 2006-07-19 09:38:04 UTC
*** Bug 131054 has been marked as a duplicate of this bug. ***
Comment 19 gmud 2006-07-19 10:00:25 UTC
I can confirm that this bug still exists in 3.5.3. See duplicate bug #131054.
Comment 20 Tommi Tervo 2006-09-21 13:34:55 UTC
*** Bug 134018 has been marked as a duplicate of this bug. ***
Comment 21 Tommi Tervo 2006-11-20 15:44:49 UTC
*** Bug 137624 has been marked as a duplicate of this bug. ***
Comment 22 Tommi Tervo 2006-12-19 13:30:04 UTC
David found this bug too...
http://lists.kde.org/?l=kfm-devel&m=116645112724652&w=2
Comment 23 Tommi Tervo 2007-02-02 10:15:34 UTC
*** Bug 129389 has been marked as a duplicate of this bug. ***
Comment 24 gmud 2007-03-02 11:05:18 UTC
*bump* Whats the status of this bug? It is really annoying and it prevents me from using some nice ajax functions with konqi.
Comment 25 gmud 2007-03-02 11:12:33 UTC
Created attachment 19862 [details]
TC: Submits the form twice and crashed
Comment 26 Tommi Tervo 2007-03-14 08:34:14 UTC
*** Bug 128816 has been marked as a duplicate of this bug. ***
Comment 27 gmud 2007-04-01 11:24:27 UTC
About the above tc: I just noticed that this has something to do with the confirm dialog that comes up if you send data to a webserver. If you use my tc with https there will be no confirm dialog and the crash won't occur.
Comment 28 Tommi Tervo 2007-04-30 07:21:00 UTC
*** Bug 144852 has been marked as a duplicate of this bug. ***
Comment 29 Erik Keever 2007-07-27 23:28:36 UTC
I'm on KDE-3.5.5 / AMD64 / Gentoo and that darned bug crashes Konqueror here too. If it'll help, I have a valgrind trace of the bad reads here:

http://ejksdesktop.homelinux.com/linux/kdecrash
Comment 30 Tommi Tervo 2008-01-22 21:26:06 UTC
*** Bug 156408 has been marked as a duplicate of this bug. ***
Comment 31 Nic Gould 2008-04-06 14:07:51 UTC
Tested in 4.0.3 - with the attached test case from 2004 I could not reproduce the problem, was prompted with the 'send unencrypted data' warning, clicked ok and the form submitted with out causing a crash.

With the second attached test case from 2007 I partially reproduced the problem. The form submitted twice, I got a send files warning, then a send unencrypted data warning, then the same two warnings again. Konq did not crash though
Comment 32 James Spahlinger 2008-04-22 03:22:55 UTC
No crash in konq 4.0.3 - no send unencrypted data warning. for me, but two popups about sending it.
No crash in konq 3.5.9 - no send unencrypted data warning. for me, but two popups about sending it.

I'm going to drop the severity from crash to normal. The two popups should not happen, but there at least is no crash.
Comment 33 Jostein Bø Fløystad 2008-08-13 19:16:52 UTC
Konqueror 3.5.9 (from Ubuntu packages) still crashes after like described in the original bug report. How to reproduce:

1) Using Horde webmail, choose write a new message (this opens a new window) and include an attachment. 
2) Press send.
3) Konqueror asks if the file should really be uploaded. Press send file.
4) The email is sent, the write message window is closed and a new confirmation (do you really want to send this file) is opened.
5) Press Send file or Cancel (it doesn't matter).
6) Konqueror crashes with SIGSEGV.

When starting konqueror from console, stdout has no output. Stderr has the following output:

QGDict::hashKeyString: Invalid null key
QGDict::hashKeyString: Invalid null key
konqueror: ERROR: : couldn't create slave : Kan ikke lage iu-slave:
klauncher sa: Ukjent protokoll «».
konqueror: 
QGDict::hashKeyString: Invalid null key
konqueror: ERROR: : couldn't create slave : Kan ikke lage iu-slave:
klauncher sa: Ukjent protokoll «».
konqueror: 
KCrash: Application 'konqueror' crashing...

(Translations: "Kan ikke lage iu-slave:" = "Cannot create io-slave";
"Ukjent protokoll" = "Unknown protocol")

Backtrace from KCrash:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb66156c0 (LWP 9618)]
[KCrash handler]
#6  KHTMLPart::submitForm (this=0x0, action=0xb5f5288b "post", 
    url=@0xbfc68ce0, formData=@0xbfc68cc8, _target=@0xbfc68cdc, 
    contentType=@0xbfc68cd8, boundary=@0x8e5bb08)
    at /build/buildd/kdelibs-3.5.9/./khtml/khtml_part.cpp:4733
#7  0xb5db0869 in DOM::HTMLFormElementImpl::submit (this=0x8e5ba80)
    at /build/buildd/kdelibs-3.5.9/./khtml/html/html_formimpl.cpp:640
#8  0xb5db1202 in DOM::HTMLFormElementImpl::prepareSubmit (this=0x8e5ba80)
    at /build/buildd/kdelibs-3.5.9/./khtml/html/html_formimpl.cpp:553
#9  0xb5db125f in DOM::HTMLInputElementImpl::activate (this=0x8eb8d30)
    at /build/buildd/kdelibs-3.5.9/./khtml/html/html_formimpl.cpp:1825
#10 0xb5db1353 in DOM::HTMLInputElementImpl::defaultEventHandler (
    this=0x8eb8d30, evt=0x8ef3320)
    at /build/buildd/kdelibs-3.5.9/./khtml/html/html_formimpl.cpp:1808
#11 0xb5d60e07 in DOM::NodeImpl::dispatchGenericEvent (this=0x8eb8d30, 
    evt=0x8ef3320)
    at /build/buildd/kdelibs-3.5.9/./khtml/xml/dom_nodeimpl.cpp:398
#12 0xb5d60fdf in DOM::NodeImpl::dispatchEvent (this=0x8eb8d30, 
    evt=0x8ef3320, exceptioncode=@0xbfc68e88, tempEvent=true)
    at /build/buildd/kdelibs-3.5.9/./khtml/xml/dom_nodeimpl.cpp:342
#13 0xb5d6181c in DOM::NodeImpl::dispatchUIEvent (this=0x8eb8d30, _id=3, 
    detail=1) at /build/buildd/kdelibs-3.5.9/./khtml/xml/dom_nodeimpl.cpp:550
#14 0xb5d60f75 in DOM::NodeImpl::dispatchGenericEvent (this=0x8eb8d30, 
    evt=0x8eb8bf0)
    at /build/buildd/kdelibs-3.5.9/./khtml/xml/dom_nodeimpl.cpp:402
#15 0xb5d60fdf in DOM::NodeImpl::dispatchEvent (this=0x8eb8d30, 
    evt=0x8eb8bf0, exceptioncode=@0xbfc69038, tempEvent=true)
    at /build/buildd/kdelibs-3.5.9/./khtml/xml/dom_nodeimpl.cpp:342
#16 0xb5d006b9 in KHTMLView::dispatchMouseEvent (this=0x8e21b98, eventId=4, 
    targetNode=0x8eb8d30, targetNodeNonShared=0x8eb8d30, 
    cancelable=<value optimized out>, detail=1, _mouse=0xbfc69108, 
    setUnder=true, mouseEventType=1)
    at /build/buildd/kdelibs-3.5.9/./khtml/khtmlview.cpp:3197
#17 0xb5d0117a in KHTMLView::viewportMouseReleaseEvent (this=0x8e21b98, 
    _mouse=0xbfc691d0)
    at /build/buildd/kdelibs-3.5.9/./khtml/khtmlview.cpp:1315
#18 0xb5d0aca2 in KHTMLView::eventFilter (this=0x8e21b98, o=0x8eb8fb0, 
    e=0xbfc69610) at /build/buildd/kdelibs-3.5.9/./khtml/khtmlview.cpp:1951
#19 0xb6c33492 in QObject::activate_filters (this=0x8eb8fb0, e=0xbfc69610)
    at kernel/qobject.cpp:906
#20 0xb6c33510 in QObject::event (this=0x8eb8fb0, e=0xbfc69610)
    at kernel/qobject.cpp:738
#21 0xb6c6bd65 in QWidget::event (this=0x8eb8fb0, e=0xbfc69610)
    at kernel/qwidget.cpp:4681
#22 0xb6bc9c36 in QApplication::internalNotify (this=0xbfc69ee8, 
    receiver=0x8eb8fb0, e=0xbfc69610) at kernel/qapplication.cpp:2638
#23 0xb6bcbde5 in QApplication::notify (this=0xbfc69ee8, receiver=0x8eb8fb0, 
    e=0xbfc69610) at kernel/qapplication.cpp:2424
#24 0xb739d672 in KApplication::notify (this=0xbfc69ee8, receiver=0x8eb8fb0, 
    event=0xbfc69610)
    at /build/buildd/kdelibs-3.5.9/./kdecore/kapplication.cpp:550
#25 0xb6b5a301 in QApplication::sendSpontaneousEvent (receiver=0x8eb8fb0, 
    event=0xbfc69610) at kernel/qapplication.h:526
#26 0xb6b58f8d in QETWidget::translateMouseEvent (this=0x8eb8fb0, 
    event=0xbfc69a58) at kernel/qapplication_x11.cpp:4306
#27 0xb6b5712f in QApplication::x11ProcessEvent (this=0xbfc69ee8, 
    event=0xbfc69a58) at kernel/qapplication_x11.cpp:3483
#28 0xb6b6e943 in QEventLoop::processEvents (this=0x8085ff8, flags=4)
    at kernel/qeventloop_x11.cpp:195
#29 0xb6be4f90 in QEventLoop::enterLoop (this=0x8085ff8)
    at kernel/qeventloop.cpp:201
#30 0xb6be4c8e in QEventLoop::exec (this=0x8085ff8)
    at kernel/qeventloop.cpp:148
#31 0xb6bcb7df in QApplication::exec (this=0xbfc69ee8)
    at kernel/qapplication.cpp:2761
#32 0xb7eb390a in kdemain () from /usr/lib/libkdeinit_konqueror.so
#33 0x080484b2 in ?? ()
#34 0xb7bad450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x08048421 in ?? ()

Hope this can help.

Jostein.
Comment 34 FiNeX 2008-11-19 20:24:18 UTC
Changed severity to "crash". I hope to have selected only the right bugs (>100) :-)
Comment 35 Icekiss 2009-04-18 13:40:03 UTC
Confirmed in KDE 4.2.2
Comment 36 Dario Andres 2009-09-30 22:55:55 UTC
Bug 192755 was fixed already. Can you check if this is also fixed in the next KDE4 version? (I'm not really sure if it is going to make it for 4.3.2)
Thanks
Comment 37 Gérard Talbot (no longer involved) 2011-08-31 00:18:32 UTC
Is this bug still happening, active?

I have not read the whole bunch of comments but this code

<FORM NAME="search" ACTION="action" METHOD="GET">
   <INPUT TYPE="text" SIZE=15
onKeyPress="if(event.which==13) {document.search.submit()}">
   <INPUT TYPE="submit" VALUE="BOOM">
 </FORM>

may well indeed (and rightly so) trigger a submit confimation dialog to appear twice. The submit() invokation may trigger the onsubmit event handler in some browsers and may *_not_* trigger it (or not correctly) in others.

onKeyPress="if(event.which==13) {document.search.submit();}

The possibly only single reason why this code may seem popular is because of an IE6, IE7 and IE8 bug which I reported myself a few years ago:

http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug204
Submit button value not posted with form submission 
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/not-submitting-submit-value.html

The bug has been fixed in IE9 PP5 (beta 1) according to the_dees:
See bug #134 in 
http://the-dees.webs.com/iepp1/

------------

(In reply to comment #34)
> Changed severity to "crash".

Regarding the subsequent crash after closing the 2nd confirmation modal window, that is in fact another clearly distinct, clearly separate bug. The system, it seems, is not able to handle running into multiple modal windows (alert, prompt, debug when having JS debugger on/active on errors) by stopping js execution accordingly.

There are at least 2 other bug reports to that effect:

bug 279605: Opening javascript debugger hangs the application (CPU %tage activity remains, stays high)

bug 278067: multiple firing of alert dialog cause reproducible application crashes

-----------

I do not understand why people file bug reports but do not answer/reply back when asked if the bug (this one has 75 votes!) is fixed or is still happening.

regards, Gérard
Comment 38 Rudo Thomas 2011-08-31 01:14:32 UTC
> I do not understand why people file bug reports but do not
> answer/reply back when asked if the bug (this one has 75 votes!) is
> fixed or is still happening.

Being the one who filed this bug, I will answer at least this part of
your message.

The answer is simpler than you might think: I gave up on the "Warn on
sending unencrypted data" setting ages ago, and on Konqueror a couple of
years later.

I wanted to give it a go now, but the Kubuntu I happen to be running no
longer has Konqueror! Sorry...

R.
Comment 39 Gérard Talbot (no longer involved) 2011-08-31 04:10:42 UTC
> I gave up on (...) Konqueror a couple of years later.
> 
> Kubuntu (...) no longer has Konqueror!

Rudo,

I use Konqueror 4.7.0 with Kubuntu 11.04 (thanks to PPA backports). I do not even know where a Konqueror user can turn on (or off) "Warn on sending unencrypted data" in Konqueror. The modal confirmation dialog window I get is rather normal and expectable:

"
Vous êtes sur le point de transférer les fichiers suivants depuis votre ordinateur local vers l'Internet.
Voulez-vous vraiment continuer ?
"

which, in French, is saying (could be translated to)

"
You are about to transfert the following files from your local computer to the Internet. 
Do you want to continue?
"

I just tried attachment 6867 [details] 
https://bugs.kde.org/attachment.cgi?id=6867

and

https://bugs.kde.org/attachment.cgi?id=19162
attachment 19862 [details]

and did not crash but there was 2 modal dialog "Confirmation to send" windows with attachment 19162 [details].

I think the code 

<form  name="tcform" id="tcform1" class="formular" action="testcase-filedouble.html" method="POST" enctype="multipart/form-data">
File:<input  name="filefield" type="file" size="20" maxlength="255" id="filefield" class="filefield" value="" />
<input  name="ajaxsubmit" type="submit" id="send" class="button" onclick="prepareFileupload();document.tcform.submit();" value="Test" />
</form>

should be instead and should have been instead

<form  name="tcform" id="tcform1" class="formular" action="testcase-filedouble.html" method="POST" enctype="multipart/form-data" onsubmit="prepareFileupload();">
File:<input  name="filefield" type="file" size="20" maxlength="255" id="filefield" class="filefield" value="" />
<input  name="ajaxsubmit" type="submit" id="send" class="button" value="Test" />
</form>

A click event on a submit button is going to submit its form elements: that's to be expected for sure... what else would one reasonably expect from such event to begin with... 


Okay. After thinking, checking, etc., I think, as far as I am concerned, this bug should be resolved as WORKSFORME (that is because we don't know for sure which patch fix the original issue in this bug): that's the proper way to do this in bug reports.

regards, Gérard
Comment 40 Myriam Schweingruber 2012-06-18 17:43:34 UTC
Closing based on comment #39