javascript support is disabled.

[Kenny Hitt]

Although javascript support in elinks isn't complete yet, it is already useful. Especially to blind users who don't have another satisfactory alternative. Please consider enabling javascript support.

[Micah Cowan (micahcowan)]

Huh. I didn't know elinks had JavaScript support... that's... cool!

If it's an experimental feature, though, it might be unwise to enable it on the normal binary package... perhaps it could be made as a separately built package (say, elisp-ecmascript).

[Kenny Hitt (kenny-hittsjunk)]

Hi.

On Wed, Oct 04, 2006 at 08:16:35PM -0000, Micah Cowan wrote:
> Huh. I didn't know elinks had JavaScript support... that's... cool!
>
> If it's an experimental feature, though, it might be unwise to enable it
> on the normal binary package... perhaps it could be made as a separately
> built package (say, elisp-ecmascript).
>
> --

It uses the spidermonkey package for it's javascript. Not all features
have been implemented yet in elinks code, that is why it is considered
experimental.

          Kenny

[Micah Cowan (micahcowan)]

On Wed, 2006-10-04 at 20:36 +0000, Kenny Hitt wrote:
> On Wed, Oct 04, 2006 at 08:16:35PM -0000, Micah Cowan wrote:
> > Huh. I didn't know elinks had JavaScript support... that's... cool!
> >
> > If it's an experimental feature, though, it might be unwise to enable it
> > on the normal binary package... perhaps it could be made as a separately
> > built package (say, elisp-ecmascript).

(Of course, I meant elinks-ecmascript above)

> It uses the spidermonkey package for it's javascript. Not all features
> have been implemented yet in elinks code, that is why it is considered
> experimental.

Yes; but in many cases, incomplete JavaScript support can be worse than
none at all, for browsing the web. That's not usually the case for web
spiders.

For instance, sites that have both JavaScript and non-script support
often have a conditional block which says "if they have JavaScript, then
do this, if not, then do this" (<script>, <noscript>). The problem is
that if full support for ECMAScript and/or mainstream JavaScript
constructs is not available, the <script> block may fail to work, and
the <noscript> block won't be evaluated (since it's presumed that you
have JavaScript). Often, feature-tests are performed in well-written
JavaScript, but few indeed perform feature-tests of anything that's
known to be available in all mainstream browsers, and feature-tests may
not be available for everything, anyway. So it could be unwise to enable
JavaScript by default.

If the elinks support for JavaScript can be enabled with a flag, and
left disabled by default, then I suppose it might be alright to include
the support in the default build, though.

This is, of course, only my 2¢, and I am not the one who will be making
decisions on this... that would probably be Martin Pitt or Peter Gervai,
or some other MOTU at least.

[Kenny Hitt (kenny-hittsjunk)]

Hi.

On Wed, Oct 04, 2006 at 09:30:06PM -0000, Micah Cowan wrote:
>
> Yes; but in many cases, incomplete JavaScript support can be worse than
> none at all, for browsing the web. That's not usually the case for web
> spiders.
>
> For instance, sites that have both JavaScript and non-script support
> often have a conditional block which says "if they have JavaScript, then
> do this, if not, then do this" (<script>, <noscript>). The problem is
> that if full support for ECMAScript and/or mainstream JavaScript
> constructs is not available, the <script> block may fail to work, and
> the <noscript> block won't be evaluated (since it's presumed that you
> have JavaScript). Often, feature-tests are performed in well-written
> JavaScript, but few indeed perform feature-tests of anything that's
> known to be available in all mainstream browsers, and feature-tests may
> not be available for everything, anyway. So it could be unwise to enable
> JavaScript by default.
>
> If the elinks support for JavaScript can be enabled with a flag, and
> left disabled by default, then I suppose it might be alright to include
> the support in the default build, though.
>
> This is, of course, only my 2¢, and I am not the one who will be making
> decisions on this... that would probably be Martin Pitt or Peter Gervai,
> or some other MOTU at least.
>

I just managed to build elinks with javascript support on my Debian Sid
box. You can build elinks with javascript support and then disable it
in the option manager.

          Kenny

[Micah Cowan (micahcowan)]

Adding SpiderMonkey support would require an extra dependency (on libmozjs0d)... but if people were worried about disk space, they'd use elinks-lite instead.

[Daniel Robitaille (robitaille)]

Adding my vote that it would be nice to have that option available, if an user want to enable it.

[DickeyWang (invariance)]

 According to the elinks manual, it seems autoconf should be able to enable javascript as long as libmozjs-dev is installed( in Debian), but it doesn't seems to be the case in Gutsy.
I am trying to build elinks with javascript, but it seems autoconf could not detect SpiderMonkey and keeps automatically disable the option for javascript, even if libmozjs0d-dev is installed.
Any suggestions?

[DickeyWang (invariance)]

OK, just realized if you make a symbolic link by running " sudo ln -s /usr/include/mozjs /usr/include/smjs" before you run configure, the autoconf will detect SpiderMonkey, and then you can generate the deb file by dpkg-buildpa

[Y Giridhar Appaji Nag (appaji)]

Upstream discourages enabling JavaScript support right now (0.11 and 0.12 series) because of several issues.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428549#10

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

 Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - the Jaunty Jackalope.

If you need a fix for the bug in previous versions of Ubuntu, please follow the instructions for "How to request new packages" at https://help.ubuntu.com/community/UbuntuBackports#request-new-packages