I don't think there is any point in keeping this file when users can
easily run elinks -no-home -config-dump to get an equivalent one.
The result won't include options for features that were disabled at
configure time, but the users won't need those options either.
Furthermore, if this file is installed as /etc/elinks/elinks.conf like
contrib/debian/rules does, and people then modify it, they cannot
easily upgrade to changed defaults in later ELinks versions; these
changes may even be security-related, like ecmascript.enable in the
upcoming ELinks 0.12.0. It is better if /etc/elinks/elinks.conf
contains only the settings that the sysadmin explicitly wants to
change from the defaults, and all the rest comes from the elinks
binary.
A problem with \n replacement caused test no. 19 to fail.
Fix it by also allowing expected output to be prepared in a
file by introducing a new backend: test_output_equals_file,
also used test_output_equals.
Tested on Ubuntu Feisty Fawn with both /bin/bash and /bin/sh
where /bin/sh failed before the fix. Reported by Witek.
Don't look for gettext message catalogs in ../po/ unless ELinks is being
run as src/elinks, ./src/elinks, or .../src/elinks.
Discovered by Arnaud Giersch, this alternate fix (than what is in debian
package 0.11.1-1.4) closes debian bug #417789 and redhat bug #235411.
Also reported in: CVE-2007-2027.
Restricting it to only work with --enable-debug was also considered,
however, it is an important feature for translaters so this less
paranoid fix was chosen.
Revert commit 2d6840b9bd9d3a7a45a5ad92b4e98ff7224d6d97. It is causing
passive FTP via IPv6 to fail on ftp.funet.fi. ELinks sends PASV and
the server says "425 You cannot use PASV on IPv6 connections. Use EPSV
instead."
Because the renderer no longer does that.
The comment "We don't cope well with entities here" may now be
obsolete but I'm not sure about that so I'm leaving it in.
options->cp is still used for this in seven places where html_context
is not easily available. Those should eventually be corrected too,
but I'm checking this change in already because it's better than what
we had before.
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.
This does not yet fix bug 947 for the case where the document is UTF-8
and the terminal is ISO-8859-1. That will require changing charsets.c
too, it seems.
