When ELinks is parsing an XML element in from an XBEL bookmark file,
it collects the attributes of the element to the current_node->attrs
list. Previously, struct attributes had room for one string only:
the last element of current_node->attrs was the name of the first
attribute, and it was preceded by the value of the first attribute,
the name of the second attribute, the value of the second attribute,
and so on. However, when get_attribute_value() was looking for a
given name, it compared the values as well. So, if you had for
example <bookmark id="href" href="http://elinks.cz/">, then
get_attribute_value("href") would incorrectly return "href".
To fix this confusion, store values in the new member
attributes.value, rather than in attributes.name.
Change test/imgmap2.html so it can be used for testing this too.
Debian Iceweasel 3.0.4 does not appear to support such external
client-side image maps. Well, that's one place where ELinks is
superior, I guess. There might be a security problem though if ELinks
were to let scripts of the referring page examine the links in the
image map.
When ELinks runs in an X11 terminal emulator (e.g. xterm), or in GNU
Screen, it tries to update the title of the window to match the title
of the current document. To do this, ELinks sends an "OSC 1 ; Pt BEL"
sequence to the terminal. Unfortunately, xterm expects the Pt string
to be in the ISO-8859-1 charset, making it impossible to display e.g.
Cyrillic characters. In xterm patch #210 (2006-03-12) however, there
is a menu item and a resource that can make xterm take the Pt string
in UTF-8 instead, allowing characters from all around the world.
The downside is that ELinks apparently cannot ask xterm whether the
setting is on or off; so add a terminal._template_.latin1_title option
to ELinks and let the user edit that instead.
Complete list of changes:
- Add the terminal._template_.latin1_title option. But do not add
that to the terminal options window because it's already rather
crowded there.
- In set_window_title(), take a new codepage argument. Use it to
decode the title into Unicode characters, and remove only actual
control characters. For example, CP437 has graphical characters in
the 0x80...0x9F range, so don't remove those, even though ISO-8859-1
has control characters in the same range. Likewise, don't
misinterpret single bytes of UTF-8 characters as control characters.
- In set_window_title(), do not truncate the title to the width of the
window. The font is likely to be different and proportional anyway.
But do truncate before 1024 bytes, an xterm limit.
- In struct itrm, add a title_codepage member to remember which
charset the master said it was going to use in the terminal window
title. Initialize title_codepage in handle_trm(), update it in
dispatch_special() if the master sends the new request
TERM_FN_TITLE_CODEPAGE, and use it in most set_window_title() calls;
but not in the one that sets $TERM as the title, because that string
was not received from the master and should consist of ASCII
characters only.
- In set_terminal_title(), convert the caller-provided title to
ISO-8859-1 or UTF-8 if appropriate, and report the codepage to the
slave with the new TERM_FN_TITLE_CODEPAGE request. The conversion
can run out of memory, so return a success/error flag, rather than
void. In display_window_title(), check this result and don't update
caches on error.
- Add a NEWS entry for all of this.
This simplifies the callers a little and may help implement
simultaneous support for different charsets on different terminals
of the same type (bug 1064).
look_for_link() used to return 0 both when it found the closing </MAP>
tag, and when it hit the end of the file. In the first case, it also
added *menu to the memory_list; in the second case, it did not. The
caller get_image_map() supposedly distinguished between these cases by
checking whether pos >= eof, and freed *menu separately if so.
However, if the </MAP> was at the very end of the HTML file, so that
not even a newline followed it, then look_for_link() left pos == eof
even though it had found the </MAP> and added *menu to the memory_list.
This made get_image_map() misinterpret the result and mem_free(*menu)
even though *menu had already been freed as part of the memory_list;
thus the crash.
To fix this, make look_for_link() return -1 instead of 0 if it hits
EOF without finding the </MAP>. Then make get_image_map() check the
return value instead of comparing pos to eof. And add a test case,
although not an automated one.
Alternatively, look_for_link() could have been changed to decrement
pos between finding the </MAP> and returning 0. Then, the pos >= eof
comparison in get_image_map() would have been false. That scheme
would however have been a bit more difficult to understand and
maintain, I think.
Reported by Paul B. Mahol.
(cherry picked from commit a2404407ce)
Before this patch, if you first moved the cursor to link X with
move-cursor-up and similar actions, and then clicked link Y with the
mouse, ELinks would activate link X, i.e. not the one you clicked.
This happened because the NAVIGATE_CURSOR_ROUTING mode was left
enabled and made ELinks ignore the doc_view->vs->current_link
member that ELinks had updated according to the click.
Make ELinks return the session to NAVIGATE_LINKWISE mode, so that
the update takes effect.
Reported by Paul B. Mahol.
(cherry picked from commit 4086418069)
Peter Collingbourne posted to elinks-dev on 3 November 2008:
>> 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?
>
> I agree to this.
According to COPYING, such permissions should be listed in AUTHORS.
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.
c_strcasecmp and c_strncasecmp were taken from GNU coreutils 6.9,
which is copyrighted by the Free Software Foundation and licensed
under GNU GPL version 2 or later. It seems the programs in coreutils
do not normally read commands interactively. So, including coreutils
code in an interactive program such as ELinks could trigger GPLv2
section 2. c), which would require ELinks to display a copyright
notice and a warranty disclaimer each time it is started. Rewrite
those functions to remove the FSF-copyrighted code and make ELinks
not a work based on GNU coreutils.
Avoiding FSF code has the additional benefit that we won't have to ask
FSF for permission if we want to add a licence exception that allows
linking ELinks with OpenSSL. So it seems a good idea even if my
interpretation of GPLv2 2. c) is overly strict. I haven't checked
though whether there are other FSF-copyrighted portions in ELinks.
src/config/kbdbind.c (parse_keystroke): If the user types "Ctrl-i",
it should mean "Ctrl-I" rather than "Ctrl-İ", because the Ctrl-
combinations are only well known for ASCII characters. This does not
matter in practice though, because src/terminal/kbd.c converts 0x09
to (KBD_MOD_NONE, KBD_TAB) and not to (KBD_MOD_CTRL, 'I').
src/osdep/beos/beos.c (get_system_env): Changing the locale does not
affect the TERM environment variable, I think, so it should not affect
the interpretation either.
Add #include directives to fix these errors:
[CC] src/intl/gettext/l10nflist.o
cc1: warnings being treated as errors
.../src/intl/gettext/l10nflist.c: In function ‘_nl_normalize_codeset’:
.../src/intl/gettext/l10nflist.c:352: error: implicit declaration of function ‘c_tolower’
[CC] src/dom/css/scanner.o
cc1: warnings being treated as errors
In file included from .../src/dom/scanner.h:4,
from .../src/dom/css/scanner.h:4,
from .../src/dom/css/scanner.c:12:
.../src/dom/string.h: In function ‘dom_string_casecmp’:
.../src/dom/string.h:34: error: implicit declaration of function ‘c_strncasecmp’
Bug 932 is about ELinks letting control characters 0x80...0x9F through
to the terminal. It did not occur with ISO 8859-1, 8859-2, 8859-15,
or 8859-16, because the ELinks mappings for those charsets did not
include those bytes. However, the www.unicode.org versions imported
in the previous commit do include the problematic bytes.
To avoid a possible regression before the ELinks 0.12.0 release,
comment those control-character mappings out again. This workaround
should be reverted after bug 932 has been fixed properly.
Add copyright and licence notices, and a NEWS entry.
The data in the new versions is not entirely the same as what ELinks
used to have:
- Unicode/8859_1.cp: Adds control characters.
- Unicode/8859_2.cp: Adds control characters.
- Unicode/8859_4.cp: Adds some control characters that ELinks assumed
there already.
- Unicode/8859_7.cp: Adds three characters.
- Unicode/8859_15.cp: Adds control characters.
- Unicode/8859_16.cp: Adds control characters and swaps 0xA5 with 0xAB.
- Unicode/koi8_r.cp: Changes 0x95 and adds some control characters
that ELinks assumed there already.
- Unicode/macroman.cp: Changes 0xC6 and removes some control characters
that ELinks assumes there anyway.
Call stacks reported by valgrind:
==14702== at 0x80DD791: read_from_socket (socket.c:945)
==14702== by 0x8104D0C: read_more_http_data (http.c:1180)
==14702== by 0x81052FE: read_http_data (http.c:1388)
==14702== by 0x80DD69B: read_select (socket.c:910)
==14702== by 0x80D27AA: select_loop (select.c:307)
==14702== by 0x80D1ADE: main (main.c:358)
==14702== Address 0x4F4E598 is 56 bytes inside a block of size 81 free'd
==14702== at 0x402210F: free (vg_replace_malloc.c:233)
==14702== by 0x812BED8: debug_mem_free (memdebug.c:484)
==14702== by 0x80D7C82: done_connection (connection.c:479)
==14702== by 0x80D8A44: abort_connection (connection.c:769)
==14702== by 0x80D99CE: cancel_download (connection.c:1053)
==14702== by 0x8110EB6: abort_download (download.c:143)
==14702== by 0x81115BC: download_data_store (download.c:337)
==14702== by 0x8111AFB: download_data (download.c:446)
==14702== by 0x80D7B33: notify_connection_callbacks (connection.c:458)
==14702== by 0x80D781E: set_connection_state (connection.c:388)
==14702== by 0x80D7132: set_connection_socket_state (connection.c:234)
==14702== by 0x80DD78D: read_from_socket (socket.c:943)
read_from_socket() attempted to read socket->fd in order to set
handlers on it, but the socket had already been freed. Incidentally,
socket->fd was -1, which would have resulted in an assertion failure
if valgrind hadn't caught the bug first.
To fix this, add a list of weak references to sockets.
read_from_socket() registers a weak reference on entry and unregisters
it before exit. done_socket() breaks any weak references to the
specified socket. read_from_socket() then checks whether the weak
reference was broken, and doesn't access the socket any more if so.
This reverts src/{network,sched}/connection.c CVS revision 1.43,
which was made on 2003-07-03 and converted to Git commit
cae65f7941628109b51ffb2e2d05882fbbdc73ef in elinks-history.
It is pointless to check whether (c == d && c->id == d->id).
If c == d, then surely c->id == d->id, and I wouldn't be surprised
to see a compiler optimize that out.
Whereas, by taking the id as a parameter, connection_disappeared()
can check whether the pointer now points to a new struct connection
with a different id.
test/align.html: from www.czech-tv.cz
test/css/idnes_mail.html: apparently from idnes.cz
test/erreurs_en.htm: unclear origin
test/javascript_broken.html: presumably from www.hotjobs.com
test/poocs.net.html: presumably from poocs.net
I did not find in the source tree a licence to distribute any of these.
Samba 3.2.0 switched to version 3 of the GNU General Public License,
which is not compatible with GPLv2 used in ELinks. Perhaps we can
eventually relicense ELinks to "GPL version 2 or later", or resolve
this in some other way. Until then, warn distributors of binaries
about the conflict.
ELinks attempted to display a message box on file_download.term, but
it had already closed that terminal and freed the struct terminal. To
fix this, reset file_download.term pointers to NULL when the terminal
is about to be destroyed. Also, assert in download_data_store() that
file_download.term is either NULL or in the global "terminals" list.
Reported by أحمد المحمودي.
(cherry picked from commit 6e2476ea4d)
It is all in one line because <http://elinks.cz/authors.html>
is converted from AUTHORS and the conversion script is not
clever enough to know which newlines should be kept.
If the licence of ELinks is ever changed to "GNU GPL v3 or later",
I'll probably stop hacking it, but I don't want to legally forbid
such a change.
Make it clear that modified versions may also be distributed.
I am the sole copyright holder for these ELinks files
so I can replace the licence like this.
This version of the licence is used in bind-9.5.0-P2.tar.gz.
Wikipedia claims ISC made the change in July 2007 after a request
from the FSF.
The dependency table was originally in "fixed" format, so that
AsciiDoc took a fixed number of characters to the first column
and the rest to the second column. However, "OpenSSL or GNU TLS
or nss_compat_ossl" will not fit in that number of characters,
and backslash line continuation will not help because AsciiDoc
apparently parses that before it counts the characters.
I could widen the column in the AsciiDoc source but switching
to "dsv" format seems prettier.
test/optgroup.html was added on 2004-04-17 with no comment about licensing.
I contacted the author via <http://iccl.fi/feedback.cgi?id=mail>, asking
for a licence. The author noted that a developer of ELinks had originally
asked on the #debian.fi channel whether the file could be used, and he had
allowed it then. That permission grant had not been recorded in the source
tree though, and it is not clear whether modification had been allowed.
Anyway, the author now explicitly grants us the GNU free documentation
licence on this file, and is willing to consider other licences.
never_for_this_site(form) did return remember_form(form).
In ELinks 0.11.0, both functions returned int, so this was OK.
In commit 2b7788614f however, the
functions were changed to return void, as required by msg_box().
GCC still accepted the return statement but Sun Studio 11 did not.
The GNU Hurd has a bug that can make select() report an exception in a
pipe even though none has actually occurred. The typical result is
that ELinks closes the pipe through which it internally passes all
input events, such as keypresses. It then no longer reacts to what
the user is trying to do.
Work around the Hurd bug by making set_handlers() check whether the
file descriptor refers to a pipe, and if so, pretend the caller did
not provide any handler for exceptions. This is a minimal change that
avoids slowing down the select() loop itself and does not require
careful analysis of the callers to statically find out which file
descriptors might refer to pipes. The extra stat() calls may slow
ELinks down somewhat, but anyway it'll work better than it did without
the patch, and if the Hurd bug is ever fixed, we can remove the
workaround at that time.
Previously, spidermonkey_get_interpreter() and init_smjs() each called
JS_SetErrorReporter on the JSContexts they created. However,
JS_SetErrorReporter actually sets the error reporter of the JSRuntime
associated with the JSContext, and all of our JSContexts use the same
JSRuntime nowadays, so only the error_reporter() of
src/ecmascript/spidermonkey.c was left installed. Because this
error_reporter() asserts that JS_GetContextPrivate(ctx) returns a
non-NULL pointer, and init_smjs() does not set a private pointer for
smjs_ctx, any error in smjs_ctx could cause an assertion failure, at
least in principle.
Fix this by making spidermonkey_runtime_addref() install a shared
error_reporter() when it creates the JSRuntime and the first JSContext.
The shared error_reporter() then checks the JSContext and calls the
appropriate function.
The two error reporters are quite similar with each other. In the
future, we could move the common code into shared functions. I'm not
doing that yet though, because fixing the bug doesn't require it.
make_bittorrent_peer_connection() used to construct a struct uri on
the stack. This was hacky but worked nicely because the struct uri
was not really accessed after make_connection() returned. However,
since commit a83ff1f565, the struct uri
is also needed when the connection is being closed. Valgrind shows:
Invalid read of size 2
at 0x8100764: get_blacklist_entry (blacklist.c:33)
by 0x8100985: del_blacklist_entry (blacklist.c:64)
by 0x80DA579: complete_connect_socket (socket.c:448)
by 0x80DA84A: connected (socket.c:513)
by 0x80D0DDF: select_loop (select.c:297)
by 0x80D00C6: main (main.c:353)
Address 0xBEC3BFAE is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
To fix this, allocate the struct uri on the heap instead, by
constructing a string and giving that to get_uri(). This string
cannot use the "bittorrent" URI scheme because parse_uri() does not
recognize the host and port fields in that. (The "bittorrent" scheme
has protocol_backend.free_syntax = 1 in order to support strings like
"bittorrent:http://beta.legaltorrents.com/get/159-noisome-beasts".)
Instead, define a new "bittorrent-peer" URI scheme for this purpose.
If the user attempts to use this URI scheme, its handler aborts the
connection with an error; but when make_bittorrent_peer_connection()
uses a bittorrent-peer URI, the handler is not called.
This change also lets get_uri() set the ipv6 flag if peer_info->ip is
an IPv6 address literal.
Reported by Witold Filipczyk.
