Bug 27432 – [Gtk] add read-write access to HTMLOptionElement text (now that it is in the HTML5 spec)

• Component: WebKit Misc.
• Status: RESOLVED WONTFIX

[Luke Kenneth Casson Leighton]

this is part of the #16401 patch split as part of an agreement
with david.

code converted from javascript to python (and then using pywebkitgtk bindings to gobject bindings) utterly breaks - and is utterly useless - without
being able to write to the <option /> text property.

i'm also pretty sure that other language bindings to other engines such as xulrunner and mshtml provide read-write access to this property.

[Luke Kenneth Casson Leighton]

Created attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

[Mark Rowe (bdash)]

Comment on attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

Per the HTML 5 specification at <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#htmloptionelement> the text attribute on HTMLOptionElement should be read-only.

[Luke Kenneth Casson Leighton]

(In reply to comment #2)
> (From update of attachment 33061 [details])
> Per the HTML 5 specification at
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#htmloptionelement>
> the text attribute on HTMLOptionElement should be read-only.

 then why is it read-write under javascript bindings?

 reality and de-facto standards take precedence.

 your answer referencing a future specification is not accepted.

[Mark Rowe (bdash)]

Comment on attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

Marking as r- for reasons previously noted.

[Luke Kenneth Casson Leighton]

Comment on attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

sorry, mark, but the reality is that existing applications expect to be able to change text in <option> - that's supported _now_, not "in the future".

when webkit's javascript bindings remove write access to text, _then_ is the time for the gobject bindings to _also_ have write access to text removed.

so whatever reasons apply to javascript supporting write-access to this property, the exact same argument applies to the gobject bindings.

review- denied.  re-enabling review.  answer in next review is expected which takes the above line of reasoning into account.

[Sam Weinig]

Comment on attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

As I have noted in another bug, repeatedly remarking a patch for review that has been r-ed is not acceptable behavior.

[Luke Kenneth Casson Leighton]

(In reply to comment #6)
> (From update of attachment 33061 [details])
> As I have noted in another bug, repeatedly remarking a patch for review that
> has been r-ed is not acceptable behavior.

 sorry, sam, but neither is ignoring requests that information be taken
 into consideration.

 your comment does not begin with "the research material has been read
 and taken into consideration" and so this is deemed unacceptable; 
 the review- is denied and the review is re-enabled.

[Luke Kenneth Casson Leighton]

so - all that needs to be done is that a discussion is entered into in which
the questions raised are noted and the issues raised answered.

denying review without discussion and without taking the issues and needs of the users into account is simply unacceptable.

if you are unable to review and enter into discussions, perhaps due to lack of time, perhaps you might like to find someone who is willing to enter into discussions and is willing to take into consideration the needs of users and developers utilising webkit.

that would be greatly appreciated.

[Luke Kenneth Casson Leighton]

Comment on attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

sorry to be requesting a direct reviewee, eric, but you took a look at the research material and gave it due consideration.  i wonder if therefore i could ask you if you might be able to do likewise on this one?

i'm very reluctant to keep on re-requesting review like this - that i am taking a risk by doing so and breaking protocol should indicate to you that it is actually a rather key and important feature that's critically required, and would be incredibly inconvenient to have to workaround if it's not there.

[Luke Kenneth Casson Leighton]

Comment on attachment 33061 [details]
patch to make HTMLOptionElement text property read-write under gobject bindings

tell you what: based on the review requests of #27437 i'll do a better updated ChangeLog entry.
that will satisfy review criteria, and will make it easier to discuss this issue.  also i will do some research into webkit's peers, MSHTML, KHTML and XULrunner, to provide supporting evidence for this request.  perhaps, like #27437, it may be best to put !LANGUAGE_OBJECTIVE_C

[Mark Rowe (bdash)]

Given that the specification says that the property should be read-only we should not be making the property writable for any other bindings.  JavaScript is a special case as there is a wide range of existing content that is likely to rely on this behavior.  This same argument cannot be made about any other language as the property has never been writable for those languages.

[Luke Kenneth Casson Leighton]

(In reply to comment #11)
> Given that the specification says that the property should be read-only we
> should not be making the property writable for any other bindings.  JavaScript
> is a special case as there is a wide range of existing content that is likely
> to rely on this behavior.  This same argument cannot be made about any other
> language as the property has never been writable for those languages.


sorry, mark, but you're forgetting about MSHTML (which has python-win32com and much more), and XULrunner (which has native c++ bindings as well as xpcom to which there is python and java), and you're forgetting KHTML.

so the statement that it has never been made writeable for those languages is not true.  the statement that it has never been made writeable in _webkit_ for any languages _is_ however true BUT:

it is a fallacy to conclude that just because nobody _has_ made it writeable that it should not _be_ made writeable.

when somebody says, "if this feature isn't made writeable, it completely stuffs up the use of webkit because the very features that are available in javascript, for the exact same reasons, are required - REQUIRED.  i repeat REQUIRED - in the language that's being used (which is python, in this case)".

so - i would appreciate it if you would not close this bug and would listen to what i am saying, and take it into account.

i will do the research, checking to see if, in fact, HTMLOptionElement.text is writeable under the competitor language bindings to webkit - MSHTML, XULrunner and KHTML.

i trust that this research will be taken into consideration.

[Maciej Stachowiak]

Since HTML5 says the property should be read-only, we should do one of the following:

1) If other browsers make it read-write to JavaScript, we should propose a change to the HTML5 spec, and eventually make the property read-write for all language bindings.

2) If other browsers have it read-only, then we should eventually fix our JavaScript binding for this property to be read-only as well, and in the meantime not propagate the mistake to other bindings.

In any case, it seems like leaving the property read-only for other bindings is safer in the short term, since it would be an API break to remove the setter but not an API break to add it. In addition, the right outcome here is clearly less ifdefs not more - so adding an extra conditional doesn't move the code in the right direction.

[Luke Kenneth Casson Leighton]

many many apologies!

research as follows:

http://xulrunner-1.9.sourcearchive.com/documentation/1.9~a8/interfacensIDOMHTMLOptionElement.html

http://msdn.microsoft.com/en-us/library/aa769148(VS.85).aspx

whilst MSHTML allows read-write access to text, XUL does not.  this throws a spanner in the works, requiring exception handling, and thus the issue of making HTMLOtionElement.text writeable in webkit is moot.

thank you for putting up with me being so insistent, and i apologise for not having done the research earlier.

[Ian 'Hixie' Hickson]

HTMLOptionElement.text in HTML5 is no longer readonly.

[Luke Kenneth Casson Leighton]

ah - thank you, ian.  reopening this bug, because it is now not a gobject-specific issue, but a non-compliance with HTML5 specification issue.

[Luke Kenneth Casson Leighton]

(In reply to comment #13)
> Since HTML5 says the property should be read-only, we should do one of the
> following:
> 
> 1) If other browsers make it read-write to JavaScript, we should propose a
> change to the HTML5 spec,

 looks like that happened, which is great (thanks ian for the notification)

> and eventually make the property read-write for all
> language bindings.

 fortunately, from the investigations which were prompted by this discussion, the use of the read-write property which this one mirrors works absolutely fine in pyjamas-desktop.

 so, if it's altered [to match the now-updated spec], it's altered - that's great.  however, the pressure's off of the test/use-case platform [pyjamas-desktop] for the gobject bindings.  and from me, you'll no doubt be pleased to hear :)

[Martin Robinson]

The posted patch is now invalid, but should a new patch remove the #ifdef entirely?

[Martin Robinson]

I don't think we want to get too liberal with the GObject bindings API. If anything we should support a small subset of the DOM for the next version.