Check in refresh_view() whether the tab is still current; if not, skip
the draw_doc() and draw_frames() calls because draw_current_link()
called within them asserts that the tab is current. However, do
always call print_screen_status(), because that handles non-current
tabs correctly too.
I think it was not yet possible to trigger the assertion failure with
setTimeout, because input.value modifications by ECMAScript do not
trigger a redraw (bug 1035).
Avoid this warning:
[CC] src/encoding/deflate.o
cc1: warnings being treated as errors
/home/Kalle/src/elinks-0.12/src/encoding/deflate.c: In function ‘deflate_read’:
/home/Kalle/src/elinks-0.12/src/encoding/deflate.c:96: warning: ‘l’ may be used uninitialized in this function
In document.forms, each struct form has form_num and form_end members
that reserve a subrange of [0, INT_MAX] to that form. Previously,
multiple forms in the list could have form_end == INT_MAX and thus
overlap each other. Prevent that by adjusting form_end of each form
newly added to the list.
Revert 438f039bda,
"check_html_form_hierarchy: Old code was buggy.", which made
check_html_form_hierarchy attach controls to the wrong forms.
Instead, construct the dummy form ("for those Flying Dutchmans") at
form_num == 0 always before adding any real forms to the list.
This prevents the assertion failure by ensuring that every possible
form_control.position is covered by some form, if there are any forms.
Add a function assert_forms_list_ok, which checks that the set of
forms actually covers the [0, INT_MAX] range without overlapping,
as intended. Call that from check_html_form_hierarchy to detect
any corruption.
I have tested this code (before any cherry-picking) with:
- bug 613 attachment 210: didn't crash
- bug 714 attachment 471: didn't crash
- bug 961 attachment 382: didn't crash
- bug 698 attachment 239: all the submit buttons showed the right URLs
- bug 698 attachment 470: the submit button showed the right URL
(cherry picked from commit 386a5d517b)
init_js_window_object() copies the alert, open, and setTimeout methods
from the window object to the global object. My fix for bug 846 on
2006-12-10 incorrectly made the corresponding C functions refuse to
work if they were not called as methods of the window object.
JSObject instances of input_class now again contain a private pointer
directly to struct form_state. This pointer is cleared or updated
when appropriate.
Anything that frees struct form_view must now call the new function
ecmascript_detach_form_view. This function should then clear out any
dangling pointers, but that has not yet been implemented.
Anything that frees or reallocates struct form_state must now call the
new functions ecmascript_detach_form_state or ecmascript_moved_form_state.
These functions should then clear out any dangling pointers, but that has
not yet been implemented.
Rename src/ecmascript/spidermonkey/util.c to
src/ecmascript/spidermonkey-shared.c and compile it also when
CONFIG_SCRIPTING_SMJS is enabled but CONFIG_ECMASCRIPT_SPIDERMONKEY is
not. Then use its functions from src/scripting/smjs/ too. Move the
corresponding declarations, as well as the inline functions needed by
src/scripting/smjs/, from src/ecmascript/spidermonkey/util.h to
src/ecmascript/spidermonkey-shared.h.
ELinks is nowadays using two JSRuntimes and SpiderMonkey has bugs that
make it crash in such use. To work around them, ELinks will need to
be changed to use only one JSRuntime. I am planning to define and
initialize that JSRuntime in src/ecmascript/spidermonkey-shared.c,
now that it's compiled whenever either of the modules is enabled.
Commit 0b99fa70ca "Bug 620: Reset form
fields to default values on reload" made render_document() decrement
vs->form_info_len to 0 while vs->form_info remained non-NULL.
copy_vs() then copied the whole structure with copy_struct and did not
change form_info because form_info_len was 0. Both view_state
structures had form_info pointing to the same memory block, causing a
segfault when destroy_vs() tried to free that block a second time.
Reported by أحمد المحمودي.
This change avoids the following error:
gcc -DHAVE_CONFIG_H -I../../.. -I/home/Kalle/src/elinks-0.11/src -I/home/Kalle/prefix/include -I/usr/include/smjs -I/usr/include -I/usr/include/lua50 -I/usr/include -I/usr/include -O0 -ggdb -Wall -Wall -Werror -fno-strict-aliasing -Wno-pointer-sign -Wno-address -fno-strict-overflow -o search.o -c /home/Kalle/src/elinks-0.11/src/viewer/text/search.c
cc1: warnings being treated as errors
/home/Kalle/src/elinks-0.11/src/viewer/text/search.c:257: warning: 'get_search_region_from_search_nodes' defined but not used
make[3]: *** [search.o] Error 1
make[3]: Leaving directory `/home/Kalle/build/i686-pc-linux-gnu/elinks-0.11/src/viewer/text'
get_search_region_from_search_nodes is called only from
search_for_pattern, which already was inside #ifdef HAVE_REGEX_H.
(cherry picked from commit 2aec302d47)
JS_CallFunction does not support closures in SpiderMonkey versions
earlier than 1.8. Test case:
elinks.keymaps.main["\""] = function() {
elinks.keymaps.main["e"] = function() {
elinks.alert("hello!");
};
}
JS_CallFunction does not support closures in SpiderMonkey versions
earlier than 1.8. Test case:
function set_suffix(suffix) {
elinks.preformat_html = function(cached, vs) {
cached.content += suffix;
}
}
set_suffix("hello");
JS_CallFunction does not support closures in SpiderMonkey versions
earlier than 1.8. Test case:
elinks.keymaps.main["!"] = function() {
elinks.load_uri("http://www.eldar.org/cgi-bin/fortune.pl?text_format=yes",
function (cached) { elinks.alert(cached.content); });
}
elinks.keymaps.main["/"] = null;
used to crash ELinks with a segfault in JS_ObjectIsFunction.
Fix that by recognizing JSVAL_NULL explicitly and treating it as "none".
Likewise, if keymap_get_property would return "none" to ECMAScript,
return JSVAL_NULL instead.
Also document elinks.vs and elinks.action.
<kahmalo> Miciah: IMO most of contrib/smjs/README should be moved into
the ELinks manual. Specifically the parts that do not depend on
contrib/smjs/hooks.js. However manual.txt contains a notice:
"Hold blameless the authors. Any lawful use is allowed." Will
you allow that also for what is now in contrib/smjs/README?
<Miciah> Absolutely.
<Miciah> In fact, I would allow some lawless uses.
<Miciah> It seems a little silly to say that lawful uses are allowed.
This reverts commit c33d195ff4.
ELinks no longer needs to collect garbage in this situation
because it can now free cache entries even if the corresponding
SMJS objects remain.
The SpiderMonkey scripting module handles the "pre-format-html" event
by constructing a JSObject for the struct cache_entry and then calling
elinks.preformat_html(cache_entry, view_state) if such a function
exists. The problem with this was that each such JSObject kept the
struct cache_entry locked until SpiderMonkey garbage-collected the
JSObject, even if the user had not defined an elinks.preformat_html
function and the JSObject was thus never needed at all. To work
around that, the SpiderMonkey scripting module ran a garbage
collection whenever the user told ELinks to flush caches.
Remove the SpiderMonkey scripting module's use of object_lock and
object_unlock on struct cache_entry, and instead make the pointers
weak so that ELinks can free the cache_entry whenever it wants even if
a JSObject is pointing to it. Each cache_entry now has a pointer back
to the JSObject; done_cache_entry calls smjs_detach_cache_entry_object,
which follows the pointer and detaches the cache_entry and the JSObject
from each other.
This commit does not yet remove the workaround mentioned above.
It is not necessary: when a rule has multiple commands in it, GNU Make
(which ELinks requires anyway) runs them one at a time, regardless of
the -j option, and skips the remaining commands when one of them
fails, regardless of the -k option. These options take effect at the
level of targets rather than individual commands.
http://elinks.cz/community.html says bugs should be reported
to elinks-users but patches should be sent to elinks-dev.
I guess elinks-users is more appropriate here.
This is so that contrib/mkdist need not delete that explicitly
(although it still does, in order to do the right thing with
a few older versions too).
The file could apparently be removed altogether (see recent
emails on elinks-dev) but a small change like this is less
likely to cause any surprises.
