Re: hidden fields in forms broken?
Francis,
I've come across an apparent form anomaly when using dillo to test a separate application.
If I create a html form, the data submitted differs depending on whether I use "text" or "hidden" input types -- specifically, the "hidden" type is not parsed for html entities. This causes breakage when I want to set the value to the four-character string x"'y, for example.
The code for this is in html.c, around line 3077 (version 1.132), where just using the same "init_str = (value) ? value : NULL;" as most other types would work.
From the comment, it was clearly a deliberate decision to leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have been made between revisions 1.5 and 1.6, where the "submit" (and others) type explicitly had Html_parse_entities() called but the "hidden" type didn't.
I don't see any dispensation in the HTML DTD which makes "hidden" and "password" immune to the entity rules. Is the exception in dillo an oversight that just hasn't been spotted yet? Or is there some reasoning that I'm missing behind the way things are?
For reference, other web browsers I tried took the html fragment
<form> <input type=text name=plain value="x"x"> <input type=hidden name=hide value="x"x"> <input type=submit> </form>
and on submission, the URL had the same value for "plain" and "hide". In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx
This is quite an interesting issue! I digged through the historical releases and the root of the problem is very far (before 0.3.2!). As I currently see it, the SGML type for those INPUT attribute values is CDATA, so entities SHOULD/MUST be parsed!!! Does anyone know otherwise? Cheers Jorge.-
I've come across an apparent form anomaly when using dillo to test a separate application.
If I create a html form, the data submitted differs depending on whether I use "text" or "hidden" input types -- specifically, the "hidden" type is not parsed for html entities. This causes breakage when I want to set the value to the four-character string x"'y, for example.
The code for this is in html.c, around line 3077 (version 1.132), where just using the same "init_str = (value) ? value : NULL;" as most other types would work.
From the comment, it was clearly a deliberate decision to leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have been made between revisions 1.5 and 1.6, where the "submit" (and others) type explicitly had Html_parse_entities() called but the "hidden" type didn't.
I don't see any dispensation in the HTML DTD which makes "hidden" and "password" immune to the entity rules. Is the exception in dillo an oversight that just hasn't been spotted yet? Or is there some reasoning that I'm missing behind the way things are?
For reference, other web browsers I tried took the html fragment
<form> <input type=text name=plain value="x"x"> <input type=hidden name=hide value="x"x"> <input type=submit> </form>
and on submission, the URL had the same value for "plain" and "hide". In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx
This is quite an interesting issue!
I digged through the historical releases and the root of the problem is very far (before 0.3.2!).
As I currently see it, the SGML type for those INPUT attribute values is CDATA, so entities SHOULD/MUST be parsed!!!
Does anyone know otherwise?
I noticed problems with this when I was developing a web based regular expression editor, and thought it was a problem with my code, but checking with another browser, it seemed to be a Dillo bug. Also, note that Dillo breaks on code like this: <input type="hidden" name="foo" value="<b>bar</b>"> displaying "> when it shouldn't do. John.
participants (2)
-
John Bradford -
Jorge Arellano Cid