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.
Be more strict about the format accepted by the ELinks specific extension
to the -remote URL syntax. That is, commands must begin with a nonempty
sequence of ASCII alphabetic characters followed by optional whitespace and
an opening parenthesis. Also, document the syntax.
Fixes bug 830.
If ECMAScript code does obj[42], then the getProperty or setProperty
function of the JSClass of obj gets 42 as the property ID and must not
treat that as an internal error.
(Adapted from 7894e30ace in ELinks 0.12.GIT.)
The getProperty and setProperty functions of a JSClass must not assume
that the obj parameter points to an instance of that class. It might
instead point to another object that merely has an instance of the
class in its prototype chain. Thus, do not assert that JS_InstanceOf
returns true there. Instead, run the check even with CONFIG_FASTMEM,
and just return JS_FALSE if it fails.
(Adapted from aa410301f1 in ELinks 0.12.GIT.)
To use it to test whether that CGI works put the following in your
elinks.conf:
set protocol.file.cgi.policy = 1
set protocol.file.cgi.path = "/path/to/elinks/test/cgi"
Then point ELinks to the print-vars.sh script inside the CGI test directory
in the ELinks source directory.
Use the new names instead of the deprecated names to increase
the likelihood that later versions, which might lack the
backwards-compatibility wrappers, will work.
