Peter Collingbourne <[EMAIL PROTECTED]> writes: > Currently ELinks reinterprets a literal newline within the value > attribute of a hidden input field as a space character. This is > inconsistent with the HTML specification and the behaviour of other > browsers. This patch fixes the problem. Some changes are also > made to ensure that these fields are URL encoded using CR LF pairs > when submitted.
The CR LF requirements are in section 17.13.4 of HTML 4.01. Can you provide a test case with: - Two types of controls: hidden controls and textareas. - Three types of newlines: CR, LF, and CRLF. - Three ways of getting the newlines into the controls: character entity references, raw control characters, and JavaScript property assignments. Thus making 2*3*3=18 combinations in total. It would be great if this test could be automated. Perhaps with local CGI support and elinks -auto-submit? ELinks is currently licensed under GPLv2 only. I hope we can eventually change the licence to also allow later versions of GPL and permit linking with OpenSSL. Do you allow such relicensing for your patch? Do you give permission to add your name and email address to the commit information, to the AUTHORS file, and similar places (e.g. a list of contributors in release notes)? The cia.vc and ohloh.com web sites are already collecting this information and others might do so in the future.
pgpQ1Ph15j7p0.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
