Weak points:
- alignof
- js problems
Todo:
- make js work with C++ and mozjs-17
- then mozjs-24
- then mozjs-52
- then mozjs-60
- decrease number of warnings
This simplifies the callers a little and may help implement
simultaneous support for different charsets on different terminals
of the same type (bug 1064).
This patch fixes an issue whereby a newline character appearing within
a hidden input field is incorrectly reinterpreted as a space character.
The patch handles almost all cases, and includes a test case.
15/18 tests pass, but the remainder currently fail due to the fact
that ELinks does not currently support textarea scripting.
Anything that frees struct form_view must now call the new function
ecmascript_detach_form_view. This function should then clear out any
dangling pointers, but that has not yet been implemented.
Anything that frees or reallocates struct form_state must now call the
new functions ecmascript_detach_form_state or ecmascript_moved_form_state.
These functions should then clear out any dangling pointers, but that has
not yet been implemented.
In uri.post, each file name begins and ends with FILE_CHAR.
Previously, file names were not encoded, and names containing
FILE_CHAR could not be used. Because FILE_CHAR is a control
character, the user cannot directly type it in a file input field,
so ELinks asserted that the field did not contain FILE_CHAR.
However, it is possible to get FILE_CHAR in a file input field
with file name completion (ACT_EDIT_AUTO_COMPLETE), causing the
assertion to fail. Now, ELinks encodes FILE_CHAR as "%02", so it
is no longer ambiguous and the assertion is not needed.
If ELinks is being linked with SSL library, use its random number
generator.
Otherwise, try /dev/urandom and /dev/prandom. If they do not work,
fall back to rand(), calling srand() only once. This fallback is
mostly interesting for the Hurd and Microsoft Windows.
BitTorrent piece selection and dom/test/html-mangle.c still use rand()
(but not srand()) directly. Those would not benefit from being
unpredictable, I think.
In the previous version, the first event that had KBD_MOD_PASTE
entered insert mode and was consumed for that; ELinks then inserted
the characters from the remaining events. Now, to make ELinks insert
the first character too, I'm changing things so that KBD_MOD_PASTE
does not cause insert mode to be entered; instead, ELinks inserts
those characters regardless of whether insert mode is on.
Pass the session with some get_opt_* calls. These are the low-hanging fruit. Some places will be difficult because we don't have the session or for other reasons.
Update a comment in encode_multipart, which refers to html_form_control, which has since been renamed to html_special_form_control.
The comment was added with this commit:
commit b4dee890a61a6c8a27a8e4cd1dc3b3b93f1cdb08
Author: Petr Baudis <pasky@ucw.cz>
Date: Fri May 10 13:26:55 2002 +0000
Don't decode and back encode hidden form items (by mikulas, from 0.97).
The function was renamed with this commit:
commit c9d72739c715b3b0c7c6fec582780c1e8f444fc4
Author: Petr Baudis <pasky@ucw.cz>
Date: Sat Dec 18 02:22:28 2004 +0000
html_(tag|form*) -> html_special_\1, to naming prevent conflicts with HTML element handlers. As suggested by Jonas.
Use it for the actual I/O only. Previously, defining CONFIG_UTF8 and
enabling UTF-8 used to force many strings to the UTF-8 charset
regardless of the terminal charset option. Now, those strings always
follow the terminal charset. This fixes bug 914 which was caused
because _() returned strings in the terminal charset and functions
then assumed they were in UTF-8. This reduction in the effects of
UTF-8 I/O may also simplify future testing.
Previously, html_special_form_control converted
form_control.default_value to the terminal charset, and init_form_state
then copied the value to form_state.value. However, when CONFIG_UTF8
is defined and UTF-8 I/O is enabled, form_state.value is supposed to
be in UTF-8, rather than in the terminal charset.
This mismatch could not be conveniently fixed in
html_special_form_control because that does not know which terminal is
being used and whether UTF-8 I/O is enabled there. Also, constructing
a conversion table from the document charset to form_state.value could
have ruined renderer_context.convert_table, because src/intl/charsets.c
does not support multiple concurrent conversion tables.
So instead, we now keep form_control.default_value in the document
charset, and convert it in the viewer each time it is needed. Because
the result of the conversion is kept in form_state.value between
incremental renderings, this shouldn't even slow things down too much.
I am not implementing the proper charset conversions for the DOM
defaultValue property yet, because the current code doesn't have
them for other string properties either, and bug 805 is already open
for that.
I am going make fc->default_value use the charset of the document, and
recoding the string from the form history to that might lose characters.
This change also affects what ECMAScript sees in the defaultValue property.
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26091157>
says it should represent the HTML "value" attribute, so changing it
based on form history is not appropriate.
straconcat reads the args with va_arg(ap, const unsigned char *),
and the NULL macro may have the wrong type (e.g. int).
Many places pass string literals of type char * to straconcat. This
is in principle also a violation, but I'm ignoring it for now because
if it becomes a problem with some C implementation, then so will the
use of unsigned char * with printf "%s", which is so widespread in
ELinks that I'm not going to try fixing it now.
UCS_ORPHAN_CELL is currently defined as U+0020 SPACE, which was
already used before this macro, so the behaviour does not change,
but the code seems clearer now.
I searched for ' ' and 32 and 0x20 and \x20, and replaced with
UCS_ORPHAN_CELL wherever UCS_NO_CHAR was involved. However,
some BFU widgets first draw spaces and then overwrite with text;
those will require a more complex fix if UCS_ORPHAN_CELL is ever
changed to some other character.
