Version: (using KDE KDE 3.3.1) Installed from: SuSE RPMs Compiler: cc version 3.3.3 (SuSE Linux) OS: Linux We have problem with using our information system located at https://www.is.ut.ee/pls/ois/tere.tulemast Login page has some data validation put under submit button's onclick event and due to some JS logic logging in is available ONLY when submit button's onclick event is emitted. Problem is that Konqueror doesn't emit onclick JS event when Enter is pressed on keyboard. It emits correcly when submit button is pressed using mouse. Pattern 1: * open https://www.is.ut.ee/pls/ois/tere.tulemast on new window * enter foo and bar into username and password fields * press Enter OR press Tab to put focus on submit button and then press Enter. Result: form is submitted, but because submit button's onclick was not emitted empty login page is shown again instead of red unsuccessful login attempt text. Pattern 2: * open https://www.is.ut.ee/pls/ois/tere.tulemast on new window * enter foo and bar into username and password fields * click on submit button using mouse. Result: form is submitted and because of submit button's onclick red unsuccessful login attempt text is shown now. HTML 4.0 spec says: The onclick event occurs when the pointing device button is clicked over an element. This attribute may be used with most elements. Firefox, Opera and IE emit onclick on pressing Enter in form.
do you have a short test case to attach? Should be simple to create
Hi, I composed a quick test case at http://pezz.tkwcy.ee/konq-onclick.html Noticed that even pressing spacebar emits onclick correctly.
Any news on this? Submitting forms using Enter key is used by at least half of users, so I think it would affect many other sites' behaviour also.
*** Bug 82993 has been marked as a duplicate of this bug. ***
Well, I think this is more of a bad web design bug. If you want something to happen when the form is submitted, you should use an onsubmit event on the form, not an onclick on the submit button. What if there are multiple submit buttons? Which one gets the event? Firefox 1.0.4 does emit an onclick on the submit button. I have no idea what it does when there are multiple submit buttons.
Tested with Konqueror 3.4.1 and Mozilla 1.0.4 and neither of them emitted onsubmit, so your suggestion is only theoretical. Our problem is practical and we get complaints about this. Konqueror is the only modern browser with this problem I know of. http://pezz.tkwcy.ee/konq-onsubmit.html I don't see any problems with multiple submit buttons with onclick defined for each of them. IIRC there's a certain rule for default submit button if there are many of them in a form. That one emits onclick item (or onsubmit or whatever).
Nothing better with Konqueror 3.4.2
Still the same on Konqueror 3.4.91 I agree that "return to submit" is unintuitive (if common) and should not be encouraged, but a clear decision would be good here. Is this a bug? What should Konqueror do?
Here's more some more info http://ppewww.ph.gla.ac.uk/~flavell/www/formquestion.html about this. I did some tests here (with 1/2 text fields + 1/2 submit buttons). On Enter Firefox makes the first submit button successfull and emits onclick() for it. Konqueror 3.4.2 makes the first button successfull but does not emit onclick(). Internet Explorer 6.0.2800.1106 on Win98SE does not make any submit button successfull nor does emit onclick(). Strange...
Ops... my comment is about the situation when you press enter on the input box, not when you select the submit button with tab and then press enter, sorry. Pressing space on the submit button with konqueror 3.4.2-0.fc4.1 (FC4) emits onclick, pressing enter does not (which really is inconsistent). PP: I was confused by the last sentence of the report - "Firefox, Opera and IE emit onclick on pressing Enter in form." while the subject is "Pressing Enter on Submit button...".
actually I would like to be it on "Pressing Enter on Submit button", because at least for me and almost anyone whom I've asked normal procedure to use login dialogs is 1) activate first textbox using mouse (or focus is already on first text box using JS) and enter username 2) activate second textbox using TAB and enter password 3) press Enter yes, there could be "2.5) activate Submit using TAB", but I don't see it necessary because choosing correct submit button on pressing Enter is clearly defined in HTML spec. At least I remember so from the old times. To make things clearer: It's a clear usability question and should be fixed in order to make usage of Konqueror much more comfortable. 97% of users even don't know that Space can be used for pressing buttons and fast-typing keyboard-lover kind of users won't want to grab mouse just for submitting a form. It's a question of intuitive usage of browser and we really get error reports here from our users that logging in somehow doesn't succeed with Konqueror (and we know the reason for this). Make a quick search over KDE bugzilla and you see this problem described in several other reports from different angles of view. I'll maybe find them for you if this bug won't progress. It's a quite pity that such an important (IMHO at least) usability bug hasn't got fixed now almost for a year. I contribute to KDE by other ways than programming, and I would really like to see someone more skilled in KHTML/JS to fix it.
SVN commit 471912 by ggarand: send a click event also when a form is activated by pressing enter from one of the fields. Matches the behaviour of all other browsers. BUG: 91652 M +2 -2 html_formimpl.cpp --- branches/KDE/3.5/kdelibs/khtml/html/html_formimpl.cpp #471911:471912 @@ -473,7 +473,7 @@ if (it.current()->id() == ID_BUTTON) { HTMLButtonElementImpl* const current = static_cast<HTMLButtonElementImpl *>(it.current()); if (current->buttonType() == HTMLButtonElementImpl::SUBMIT && !current->disabled()) { - current->activate(); + current->click(); return; } } else if (it.current()->id() == ID_INPUT) { @@ -482,7 +482,7 @@ case HTMLInputElementImpl::SUBMIT: case HTMLInputElementImpl::IMAGE: if(!current->disabled()) { - current->activate(); + current->click(); return; } break;