When tables were rendered first time html_format_part was called with
document==NULL. <meta http-equiv=Refresh.../> was inside a table,
so document was NULL. Second time the table knew its dimensions
and document was not NULL.
[ From commit e01785e462 in ELinks
0.12.GIT. --KON ]
src/bfu/menu.c (scroll_menu): Let neither menu->selected nor pos
become -2.
src/bfu/menu.c (menu_mouse_handler): Call set_menu_selection directly
rather than via scroll_menu, as sel is already known to be selectable.
(Not required for fixing the bug.)
src/bfu/menu.c (menu_search_handler): Break infinite loops also if
menu->selected is -1 initially.
src/bfu/menu.c (menu_handler): Instead of tweaking menu->selected
directly, let scroll_menu do it.
[ From commit 0a8633d07e in ELinks
0.12.GIT. --KON ]
The bug was that menu_search_handler gave scroll_menu an incorrect
count because it didn't know that scroll_menu skips unselectable
items.
[ From commit 9fa5ae374f in ELinks
0.12.GIT. --KON ]
Old versions of add_string_to_string returned the target string
unmodified if from->source pointed to a null character, which usually
meant that the source string was empty. That was changed in commit
5e18576391f75ad84e04f9c8a30b93d08f0b92ab on 2004-11-03 so that
add_string_to_string instead returned NULL in that situation. The
change seems to have been inadvertent.
I'm now reverting that change and also making add_string_to_string
check the emptiness of the source string based on the stored length
only, rather than on any null characters. So the function can now
also be used with non-C strings containing embedded null characters.
Note that the previous version did not completely prevent embedded
null characters either, because it checked only the first character.
[ From commit 4a23d7fd82 in ELinks
0.12.GIT. --KON ]
trim_chars was called only in debug mode and the results of the get_attr_val
for value=" something " in debug mode differ from normal and fastmem mode.
[ From commit e347122e6d in ELinks
0.12.GIT. --KON ]
[ Bug 942; backported from commit 3f4de99f16
in ELinks 0.12.GIT. I omitted the part of the patch that decodes
FTP URLs for HTML TITLE, because I think it's an enhancement rather
than a bug fix. --KON ]
Previously, print_xml_entities did look up the charset, but did not
save the result anywhere and just used 0, leading to further lookups
in subsequent calls. It worked by accident though, because the
codepage index of us-ascii currently is 0.
[ Backported from commit e325b748be
in ELinks 0.12.GIT. --KON ]
This fixes parse_ftp_number to use off_t instead of long to store its
(intermediate) result and return type. It also introduces an OFFT_MAX type
"limit" that is used for validating the size of the parsed number.
A test-case for was added in 37c9bf3f75 to
test-ftp-parser and the patch has been confirmed to fix the test-case by
adamg and me. This closes bug 899, which is a duplicate of debian bug
403139.
doc/remote.txt says there must be a nonempty sequence of ASCII
alphabetic characters before the opening parenthesis. Check that
they really are ASCII characters and that the sequence is nonempty.
Thus, elinks -remote '(foo)' now treats the string as an address,
rather than as a command.
