Bug 136957

Summary:	testcase - OPTION element in SELECT does not support onclick event
Product:	[Applications] konqueror	Reporter:	Oded Arbel <oded>
Component:	khtml	Assignee:	Konqueror Bugs <konqueror-bugs-null>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	finex, matthias.hermanns, tim
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	[testcase] OPTION element doesnot fire onclick event [testcase] OPTION element doesnot fire onclick event

Description Oded Arbel 2006-11-06 17:23:25 UTC

Version:           3.5.5 (using KDE KDE 3.5.5)
Installed from:    Fedora RPMs
Compiler:          gcc 4.1 
OS:                Linux

According to W3C HTML 4.01, p 17.6 ( http://www.w3.org/TR/html4/interact/forms.html#h-17.6 ), the OPTION element inside the SELECT element should fire an onclick event when it is clicked with the mouse (when the SELECT box is displaying its option, either using a "multi" style display or with a pulldown). 

This currently does not work with Konqueror on KDE 3.5.5

Comment 1 Oded Arbel 2006-11-06 17:24:42 UTC

Created attachment 18437 [details]
[testcase] OPTION element doesnot fire onclick event

The following test case has an "onclick" event with an "alert()" call on the
second option element ("test B"). open the select list and click on "test B"
and an alert box should come up.

Comment 2 Oded Arbel 2006-11-06 17:25:41 UTC

Comment on attachment 18437 [details]
[testcase] OPTION element doesnot fire onclick event

><HTML><HEAD/><BODY>
><FORM>
><SELECT>
><OPTION>Test A</OPTION>
><OPTION onclick="alert('clicked');">Test B</OPTION>
></SELECT>
></FORM>
></BODY></HTML>

Comment 3 Oded Arbel 2006-11-06 17:27:06 UTC

Created attachment 18438 [details]
[testcase] OPTION element doesnot fire onclick event

oops - wrong upload. this is the correct one. please ignore the above 2
comments

Comment 4 Martin Fitzpatrick 2007-01-10 20:52:40 UTC

Confirmed KDE 3.5.5 / Kubuntu 6.10. Firefox fires events correctly in this case, Konqueror does not.

Comment 5 Martin Fitzpatrick 2008-04-07 13:30:04 UTC

Confirmed to still exist KDE 4.0.3 / Kubuntu.

Comment 6 FiNeX 2008-04-20 22:58:15 UTC

Bug confirmed on konqueror 4 (trunk). The alert is not shown.

Comment 7 Matthias Hermanns 2008-11-18 12:16:00 UTC

I have the same problem. Unfortunately I need the "onclick"-function because there is often only one option in my selection so that "onChange" will not work for me.

Is there any fix intended to this onClick-Problem in <option>?

Comment 8 Tim Landscheidt 2009-03-05 21:08:19 UTC

I have a similar problem when the onclick event is on the select element:

<HTML>
  <HEAD/>
  <BODY>
  <FORM>
    <SELECT onclick="alert('clicked');">
    <OPTION>Test A</OPTION>
    <OPTION>Test B</OPTION>
    </SELECT>
  </FORM>
  </BODY>
</HTML>

This works in Firefox, but not in Konqueror 4.2.00. Is this behaviour a) contradictory to the standard and/or b) related to this bug or should I open a new report?

Comment 9 Maksim Orlovich 2009-03-06 01:51:22 UTC

I think it may be best to report the problem with <select> separately, though I am not sure. The <option> report really doesn't make much sense to me because there is no visual representation of the <option> element as far as we're concerned --- it's merely structured data for the select; so how can one click something that's not on the screen?

Comment 10 Tim Landscheidt 2009-03-06 15:05:44 UTC

(In reply to comment #9)
> I think it may be best to report the problem with <select> separately, though I
> am not sure. [...]

Done with bug 186339.

Comment 11 Oded Arbel 2009-03-08 12:50:25 UTC

An <OPTION> tag is the HTML representation of the visual element that renders a single option - in a single select (dropdown) it is the representation of one item in the dropdown list.

The requirement for OPTION elements to support events is specified in all existing HTML standards, and Konqueror cannot be really considered a standard compliant browser unless it supports those - so currently Konqueror is not standard compliant HTML 4 browser. This is really sad.

Comment 12 Justin Zobel 2021-03-21 00:25:05 UTC

Thank you for the bug report.

As this report hasn't seen any changes in 10 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

Comment 13 Oded Arbel 2021-03-21 07:55:50 UTC

(In reply to Justin Zobel from comment #12)
> As this report hasn't seen any changes in 10 years or more, we ask if you
> can please confirm that the issue still persists.

Well, this bug hasn't seen any work since it was opened 15 years ago, so that is not surprising. Which brings up the question - it is relevant any more? To make sure that there was indeed no work done I had to apt-get Konqueror, because apparently KDE users running the latest Plasma no longer expect to have Konqueror available, to the point that it isn't listed in Discover (so it isn't considered an application?).

> If this bug is no longer persisting or relevant please change the status to
> resolved.

This bug can still be reproduced on the latest version of Konqueror (20.12.3) as well as the QtWebEngine-based Falkon (3.1.0). So this is likely a Qt issue? (I'm not sure what konqueror is even based on these days, and its main{?} library - libkf5konq6 - from the Neon repository claims that it is a library for KDE 4{!!} applications).

Comment 14 Christoph Cullmann 2024-05-06 18:39:55 UTC

Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann