27432 2009-07-19 15:27:24 -0700 [Gtk] add read-write access to HTMLOptionElement text (now that it is in the HTML5 spec) 2014-04-08 18:10:05 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX P2 Normal --- 16401 0 lkcl webkit-unassigned ian mjs mrobinson oldest_to_newest 133030 0 lkcl 2009-07-19 15:27:24 -0700 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. 133031 1 33061 lkcl 2009-07-19 15:29:20 -0700 Created attachment 33061 patch to make HTMLOptionElement text property read-write under gobject bindings 133043 2 33061 mrowe 2009-07-19 16:27:03 -0700 Comment on attachment 33061 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. 133048 3 lkcl 2009-07-19 16:38:26 -0700 (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. 133057 4 33061 mrowe 2009-07-19 19:25:38 -0700 Comment on attachment 33061 patch to make HTMLOptionElement text property read-write under gobject bindings Marking as r- for reasons previously noted. 133555 5 33061 lkcl 2009-07-21 12:26:46 -0700 Comment on attachment 33061 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. 133677 6 33061 sam 2009-07-21 18:48:57 -0700 Comment on attachment 33061 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. 133733 7 lkcl 2009-07-22 03:24:04 -0700 (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. 133736 8 lkcl 2009-07-22 03:29:59 -0700 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. 133738 9 33061 lkcl 2009-07-22 03:39:27 -0700 Comment on attachment 33061 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. 133754 10 33061 lkcl 2009-07-22 06:06:48 -0700 Comment on attachment 33061 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 133999 11 mrowe 2009-07-22 18:26:16 -0700 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. 134301 12 lkcl 2009-07-23 16:06:48 -0700 (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. 134442 13 mjs 2009-07-24 01:09:17 -0700 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. 134461 14 lkcl 2009-07-24 01:54:04 -0700 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. 136592 15 ian 2009-08-03 00:19:47 -0700 HTMLOptionElement.text in HTML5 is no longer readonly. 136598 16 lkcl 2009-08-03 01:21:20 -0700 ah - thank you, ian. reopening this bug, because it is now not a gobject-specific issue, but a non-compliance with HTML5 specification issue. 136641 17 lkcl 2009-08-03 08:42:41 -0700 (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 :) 257872 18 mrobinson 2010-07-29 14:11:12 -0700 The posted patch is now invalid, but should a new patch remove the #ifdef entirely? 998957 19 mrobinson 2014-04-08 18:10:05 -0700 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. 33061 2009-07-19 15:29:20 -0700 2010-06-10 17:55:50 -0700 patch to make HTMLOptionElement text property read-write under gobject bindings hoe.idl text/plain 1307 lkcl SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC02MjQwNyw2ICs2MjQxNSwxNCBAQAogICAgICAgICAqIHBsYXRmb3JtL3d4L1JlbmRlclRoZW1l V3guY3BwOgogICAgICAgICAoV2ViQ29yZTo6UmVuZGVyVGhlbWVXeDo6aXNDb250cm9sU3R5bGVk KToKIAorMjAwOC0xMS0zMCAgbGtjbCA8bGtjbEBsa2NsLm5ldD4KKworICAgICAgICBSZXZpZXdl ZCBieSBOT0JPRFkgKE9PUFMhKQorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3No b3dfYnVnLmNnaT9pZD0yNzQzMgorCisgICAgICAgICogaHRtbC9IVE1MT3B0aW9uRWxlbWVudC5p ZGw6IGFkZGVkIExBTkdVQUdFX0dPQkpFQ1Qtc3BlY2lmaWMgSURMCisKIDIwMDgtMTItMDQgIEtl dmluIFdhdHRlcnMgIDxrZXZpbndhdHRlcnNAZ21haWwuY29tPgogCiAgICAgICAgIFJldmlld2Vk IGJ5IEtldmluIE9sbGl2aWVyLgpJbmRleDogV2ViQ29yZS9odG1sL0hUTUxPcHRpb25FbGVtZW50 LmlkbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2h0bWwvSFRNTE9wdGlvbkVsZW1lbnQuaWRsCShy ZXZpc2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvaHRtbC9IVE1MT3B0aW9uRWxlbWVudC5pZGwJKHdv cmtpbmcgY29weSkKQEAgLTI4LDcgKzI4LDkgQEAKICAgICBdIEhUTUxPcHRpb25FbGVtZW50IDog SFRNTEVsZW1lbnQgewogICAgICAgICByZWFkb25seSBhdHRyaWJ1dGUgIEhUTUxGb3JtRWxlbWVu dCAgICAgIGZvcm07CiAgICAgICAgICAgICAgICAgIGF0dHJpYnV0ZSAgYm9vbGVhbiAgICAgICAg ICAgICAgZGVmYXVsdFNlbGVjdGVkOwotI2lmIGRlZmluZWQoTEFOR1VBR0VfSkFWQVNDUklQVCkg JiYgTEFOR1VBR0VfSkFWQVNDUklQVAorI2lmIChkZWZpbmVkKExBTkdVQUdFX0pBVkFTQ1JJUFQp ICYmIExBTkdVQUdFX0pBVkFTQ1JJUFQpIHx8IFwKKyAgICAoZGVmaW5lZChMQU5HVUFHRV9HT0JK RUNUKSAmJiBMQU5HVUFHRV9HT0JKRUNUKQorCiAgICAgICAgICAgICAgICAgIGF0dHJpYnV0ZSAg W0NvbnZlcnROdWxsVG9OdWxsU3RyaW5nXSBET01TdHJpbmcgICAgICAgICAgICB0ZXh0CiAgICAg ICAgICAgICAgICAgICAgICBzZXR0ZXIgcmFpc2VzKERPTUV4Y2VwdGlvbik7CiAjZWxzZQo=