Replace JS_EncodeString by jsval_to_string. It will allow easier
changes in the future. In smjs nullptr everywhere.
In ecmascript arrays don't work. For example
document.getElementsByTagName("H1")[0]
smjs even does not start.
Plan is to bump mozjs version, and later back to fixing bugs.
Lines in disallowed.txt may contain prefixes of bad sites.
If current url matches any of line with disallowed prefixes,
ecmascript is not executed.
If disallowed.txt is empty or not matched, then
if allow.txt is not empty, and some prefix from this file
matches current url, ecmascript is allowed.
If allow.txt is empty, ecmascript is allowed too,
otherwise ecmascript is disabled on given page.
In ~/.elinks/allowed_ecmascript_url_prefixes.txt you must enter list
of urls. For example:
file://
https://buildlogs.pld-linux.org/http://example
If url of document starts with one of given prefixes, then given url is
allowed to execute ecmascript. Start from most often used first.
SpiderMonkey was updated to mozjs24. If you want to build elinks
with ecmascript support, you must compile using g++ with -fpermissive .
There is a lot of warnings.
There are some memleaks in ecmascript code, especially related to JSAutoCompartment.
I don't know yet, where and how to free it.
Debian does not support mozjs24, so I'm going to gradually update SpiderMonkey version.
Weak points:
- alignof
- js problems
Todo:
- make js work with C++ and mozjs-17
- then mozjs-24
- then mozjs-52
- then mozjs-60
- decrease number of warnings
Each C function that can be called as a method of an ECMAScript object
is typically listed in a spidermonkeyFunctionSpec array and has a
comment that shows the name of the array and the name of the method.
For example, elinks_alert has a comment /* @elinks_funcs{"alert"} */
because elinks_funcs[] contains an element { "alert", elinks_alert, 1 }.
When some of those functions were split into outer and inner functions
for SpiderMonkey 1.8.5 compatibility, the comments were attached to
the inner functions, which contain the bulk of the code. Move the
comments to the outer functions, to which the array elements point.
forms_item declared a variable (jsval val), passed its address to
forms_item2, and set it as the return value. However, forms_item2
could return without initializing the jsval, especially if given too
many arguments. Fix by initializing to JSVAL_VOID right away.
I'm not sure that is the correct value to return in such cases,
but at least it's better than risking a crash.
Likewise in form_elements_item and form_elements_namedItem.
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.
(cherry picked from elinks-0.12 commit e5f6592ee2)
Conflicts:
src/protocol/fsp/fsp.c: All options had been removed in 0.13.GIT.
src/protocol/smb/smb2.c: Ditto.
Add session_class, which defines a JSObject wrapper for struct session.
Add location_array_class, which defines a JSObject wrapper for struct
ses_history. The "history" member of struct session is a struct
ses_history, which is a linked list of struct location.
Add a pointer from struct session to the session_class object and the
location_array object.
Add smjs_get_session_object to return a session_class JSObject wrapper for
a given struct session.
Add smjs_get_session_location_array_object to return a location_array_class
JSObject wrapper for a given struct session.
Add "session" property to the "elinks" object, which uses
smjs_get_session_object to get a JSObject wrapper for smjs_ses.
Add smjs_location_array_get_property, which allows indexing
a location_array object using a positive number for history forward or
a negative number for history backward.
Add session_props, session_get_property, session_set_property,
session_funcs, smjs_session_goto_url (which implements the "goto" method),
and smjs_init_session_interface for session_class.
Add session_construct, which creates a new tab and returns the JSObject
session_class wrapper.
Add session_finalize and smjs_location_array_finalize, which clear the
pointers between struct session and the JSObject wrappers in question.
Add smjs_detach_session_object, which clears the pointers between a given
struct session and the corresponding JSObject wrappers.
In destroy_session, call smjs_detach_session_object.
Add jsval_to_object helper in ecmascript/spidermonkey/util.h;
jsval_to_object is used in smjs_session_goto_url.
Modify delayed_goto_uri_frame to allow the target to be NULL.
smjs_session_goto_url needs this modification.
Add an include for config/options.h to src/ecmascript/spidermonkey.c
and two missing declarations (struct form_view and struct form_state)
to src/ecmascript/spidermonkey.h.
Implement new heartbeat code to catch runaway execution of document
ECMAScript code. The old code uses JS_SetBranchCallback which is
deprecated in new versions of SpiderMonkey. The new code uses setitimer(2)
and the JS_SetOperationCallback and JS_TriggerOperationCallback interfaces,
introduced in SpiderMonkey 1.8.1. Compatibility with both the old
JS_SetBranchCallback and the new interfaces is maintained.
This should fix a crash in:
at /home/Kalle/src/elinks-0.12/src/ecmascript/spidermonkey.c:251
at /home/Kalle/src/elinks-0.12/src/ecmascript/ecmascript.c:104
at /home/Kalle/src/elinks-0.12/src/viewer/text/vs.c:64
It seems that spidermonkey_get_interpreter failed and returned NULL to
ecmascript_get_interpreter, which did not check the return value and
behaved as if the ECMAScript interpreter had been properly initialized.
This caused destroy_vs to call ecmascript_put_interpreter, but
backend_data which should have been a JSContext * was NULL, causing
a crash in SpiderMonkey.
An alternative fix might be to make spidermonkey_put_interpreter skip
the JS_DestroyContext call if ctx is NULL. However, I think it is
better to make sure ecmascript_get_interpreter returns NULL if
spidermonkey_get_interpreter fails, so that vs->ecmascript is left
NULL and there's no chance that some other code might try to
dereference the (JSContext *) NULL.
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.
Documentation strings of most options used to contain a "\n" at the
end of each source line. When the option manager displayed these
strings, it treated each "\n" as a hard newline. On 80x24 terminals
however, the option description window has only 60 columes available
for the text (with the default setup.h), and the hard newlines were
further apart, so the option manager wrapped the text a second time,
resulting in rather ugly output where long lones are interleaved with
short ones. This could also cause the text to take up too much
vertical space and not fit in the window.
Replace most of those hard newlines with spaces so that the option
manager (or perhaps BFU) will take care of the wrapping. At the same
time, rewrap the strings in source code so that the source lines are
at most 79 columns wide.
In some options though, there is a list of possible values and their
meanings. In those lists, if the description of one value does not
fit in one line, then continuation lines should be indented. The
option manager and BFU are not currently able to do that. So, keep
the hard newlines in those lists, but rewrap them to 60 columns so
that they are less likely to require further wrapping at runtime.
This reverts commit b94657869b.
I don't know where I got the idea that JS_SetErrorReporter affects the
entire JSRuntime, rather than only the provided JSContext. The people
on #jsapi say it has never worked that way.
