The HTML parser decoded SGML entity references and numeric character
references in the following attributes, and then the renderer did the
same again:
link/@title
link/@hreflang
link/@type
link/@media
img/@alt
area/@alt
input[@type="image"]/@alt
input[@type="image"]/@name
input[@type="button"]/@value
The result was that e.g. title="A" displayed as "A"
even though it was supposed to display as "A".
Fix by making the HTML parser tell the renderer that the entities have
already been decoded.
(cherry picked from commit 715571a5d6)
Make u2cp_() map code points U+0080 to U+009F via strange_chars[] even
if the target codepage is UTF-8. This helps with buggy web pages that
use ’ when they mean ’. This change does not affect how
ELinks decodes raw bytes 0x80 to 0x9F in HTML.
u2cp_() is used only via the u2cp and u2cp_no_nbsp macros.
Possible side effects of this change at each use of these macros:
* get_translation_table(): Not affected because it does not call u2cp
if the target codepage is UTF-8.
* get_entity_string(): Numeric character references are affected, as intended.
Character entity references are not affected because entities[]
does not define any entities in the U+0080...U+009F range.
* kbd_field(), term_send_ucs(), field_op(): Affected. It is no longer
possible to enter code points U+0080...U+009F from the terminal.
This should not be a problem in practice because those would be
control characters anyway and should therefore be filtered by the
slave process (which doesn't yet recognize them; bug 777).
ELinks already allowed '+' and '*' in the names of options when
reading a configuration file. The option manager however didn't
let the user add such options. Allow the characters there too.
These characters are needed especially in the mime.type tree,
where '*' is used as a replacement for '.'. For example:
set mime.type.audio.prs*sid = "sid"
set mime.type.application.atom+xml = "atom"
This commit changes one gettextised string.
INIT_OPTION used to initialize union option_value at compile time by
casting the default value to LIST_OF(struct option) *, which is the
type of the first member. On sparc64 and other big-endian systems
where sizeof(int) < sizeof(struct list_head *), this tended to leave
option->value.number as zero, thus messing up OPT_INT and OPT_BOOL
at least. OPT_LONG however tended to work right.
This would be easy to fix with C99 designated initializers,
but doc/hacking.txt says ELinks must be kept C89 compatible.
Another solution would be to make register_options() read the
value from option->value.tree (the first member), cast it back
to the right type, and write it to the appropriate member;
but that would still require somewhat dubious conversions
between integers, data pointers, and function pointers.
So here's a rather more invasive solution. Add struct option_init,
which is somewhat similar to struct option but has non-overlapping
members for different types of values, to ensure nothing is lost
in compile-time conversions. Move unsigned char *path from struct
option_info to struct option_init, and replace struct option_info
with a union that contains struct option_init and struct option.
Now, this union can be initialized with no portability problems,
and register_options() then moves the values from struct option_init
to their final places in struct option.
In my x86 ELinks build with plenty of options configured in, this
change bloated the text section by 340 bytes but compressed the data
section by 2784 bytes, presumably because union option_info is a
pointer smaller than struct option_info was.
decompress_data() supposed that read_encoded() would return a positive
number if it decompressed something, 0 if no data is available yet but
may be later, or -1 if no more data will be available. However,
several backends actually returned 0 if they had seen an EOF marker or
an error in the stream, causing decompress_data() to keep calling
them. Make them return -1 in this situation.
Perhaps because of bug 981, if one opened hundreds of pages with
elinks --remote openURL(...), then ELinks 0.11.4 could crash with a
SIGSEGV in JS_InitClass called from spidermonkey_get_interpreter.
SpiderMonkey ran out of memory and began returning NULL and JS_FALSE
but ELinks didn't notice them and pressed on. Add some checks to
avoid the crash, although the underlying out-of-memory error remains.
ELinks 0.12pre4 has already been released and will not be modified.
Eventually, new changes will be made in ELinks 0.11.6.GIT and then
listed in this file. At that time, it would be wrong to claim that
0.12pre4 also includes the changes.
Avoid compilation error with GNUTLS 1.2.9:
/home/Kalle/src/elinks-0.12/src/network/ssl/ssl.c:258: error: implicit declaration of function ‘gnutls_priority_set_direct’
If the function is not available, use gnutls_set_default_priority instead.
Perhaps it'll work with bugzilla.novell.com, perhaps not.
- gnutls_handshake_set_private_extensions: Do not enable private cipher
suites that might not be supported by anything other than GNUTLS.
The GNUTLS 2.8.0 documentation notes that enabling these extensions
can cause interoperability problems.
- gnutls_set_default_priority: Explicitly disable OpenPGP certificates.
- gnutls_certificate_type_set_priority: Do not enable OpenPGP certificates.
The GNUTLS 2.8.0 documentation notes that OpenPGP certificate support
requires libgnutls-extra. Because libgnutls-extra 2.2.0 and later are
under GPLv3-or-later and thus not GPLv2 compatible, ELinks doesn't use
libgnutls-extra, so OpenPGP certificates didn't work anyway.
- gnutls_server_name_set: Do not tell the server the hostname from the URL.
This was supposed to let the server choose the appropriate certificate
for each name-based virtual host, but ELinks actually always sent just
"localhost", so it didn't work anyway. This will have to be revisited
when ELinks is changed to actually verify the subject name from the
server's certificate (ELinks bug 1024).
These changes should help ELinks negotiate SSL with bugzilla.novell.com.
[NEWS and commit message by me. --KON]
The configure script used to run libgnutls-config in order to find the
compiler and linker options needed for using GNUTLS, but GNUTLS 2.7
apparently doesn't ship that script any more. Use pkg-config instead.
GNUTLS 1.2.0 is the oldest version supported by ELinks, and that already
installs the gnutls.pc file required by pkg-config.
This commit also removes support for configure --with-gnutls=DIR.
The configure script used to look for libgnutls-config in DIR.
DIR thus had to be a directory where executable programs were installed,
and it's unlikely that gnutls.pc would be found there. So, any callers
that used this feature would have to be changed anyway, and they can as
well be changed to set the PKG_CONFIG_PATH environment variable instead.
The AsciiDoc 7.1.2 configuration files included in the ELinks
source tree apparently aren't compatible with AsciiDoc 8.4.4:
[ASCIIDOC] doc/elinks.1.xml
FAILED: [listdef-bulleted] missing section: [listtags-None]
make[1]: *** [elinks.1.xml] Error 1
Fix this by including asciidoc.py from AsciiDoc 7.1.2 as well.
The build system now doesn't care at all whether the user has
installed some version of AsciiDoc or not.
C99 6.7.4p3 and 6.7.4p6 set some constraints on what can be done in
inline functions and how they can be declared. In particular, any
function declared inline must also be defined in the same translation
unit. To comply with that, remove inline specifiers from function
declarations in header files when the functions are not also defined
in those header files.
Sun Studio 11 on Solaris 9 is stricter than C99 and does not allow
references to static identifiers in extern inline functions. Make the
configure script detect this and define NONSTATIC_INLINE accordingly
in config.h. Then use that in the definitions of all non-static
inline functions.
Document the restrictions and this scheme in doc/hacking.txt.
Check the return value of get_opt_rec on "document.browse.search.regex"
before dereferencing it. The option is not there if regular expression
support is disabled at build time.
This commit fixes a bug introduced in commit
b2d51c75ff0d6c52a4f6a2761801beb641cba3a2.
