webperl icon indicating copy to clipboard operation
webperl copied to clipboard

Unexpected termination in JS.do console

Open daotoad opened this issue 5 years ago • 4 comments
trafficstars

Describe the bug Running a simple, valid program in the JS.do example website may lead to a valid script terminating.

Error message is: Operation """": no method found, argument in overloaded package WebPerl::JSObject. exit(255) called, but NO_EXIT_RUNTIME is set, so halting execution but not exiting the runtime or preventing further async execution (build with NO_EXIT_RUNTIME=0, if you want a true shutdown)

To Reproduce

  1. Open https://js.do/perl/
  2. Paste and run this program:
use v5.28;
use WebPerl 'js';
use strict;
use warnings;

my $doc = js("document");
say $doc->{location}{href};

my $p = $doc->createElement('p');
$p->{innerText} = "I am perldom";
$p->{style}{cssText} = 'background: green; border: 3px red solid;';

my $container = $doc->{body}->querySelector('div.container');
$container->appendChild( $p );
#1
  1. Note that the code runs and then show an error message.
  2. Uncomment the last line, so that '1' is now a statement
  3. Click run, the code will work without errors.

Expected behavior vs. actual behavior

This code should run identically with or without the trailing constant.

Versions

  • Device: desktop
  • OS: OSX 10.14.4 (18E226)
  • Browser and version: Safari Version 12.1 (14607.1.40.1.4)
  • WebPerl: whatever is hosted on js.do

Additional context Add any other context about the problem here. If applicable, add screenshots to help explain your problem.

daotoad avatar Apr 13 '20 19:04 daotoad

Thanks for the report. Unfortunately at this moment the js.do website seems to be down, but I have a suspicion as to what's going on: probably the surrounding code is attempting to use the return value from this piece of code as a string, which means it's trying to stringify the return value of $container->appendChild( $p );, which WebPerl::JSObject doesn't support. This link should emulate the same problem.

For now, your workaround of adding the extra 1; statement at the end is fine, as it alters the return value of the script. Once js.do is back up I can take a look at what it's doing. But at the same time, adding the possibility to stringify WebPerl::JSObject is something I could probably add in the next release. Thanks!

haukex avatar Apr 14 '20 08:04 haukex

Unfortunately I couldn't reproduce this yet. See https://js.do/code/webperltest1 - it seems to work fine, at least in Firefox on Linux. Could you let me know if this code fails for you on your platform? And if not, could you provide a link to code that does fail on your platform? Thanks.

haukex avatar Apr 14 '20 18:04 haukex

I made this report based on testing from a computer I no longer have access to.

Testing from my personal system I get the following results:

  • Safari Version 12.1.2 (14607.3.9)

    • works
    • very slow, takes almost 30 seconds to run, consuming over two full CPUs to run.
  • Google Chrome Version 81.0.4044.122 (Official Build) (64-bit)

    • works
    • still slow, taking several seconds to run, but significantly faster than safari, eats about 75% of one CPU.
  • Firefox 75.0 (64-bit)

    • works
    • Quite fast. I don't have time to find the CPU consumption in Activity Monitor before the run is complete.

I'd be willing to bet that the speed issues on Safari are more of a commentary on webasm support in the browsers than anything you are doing.

daotoad avatar Apr 27 '20 21:04 daotoad

Thanks for the update! And yes, Webassembly support isn't perfect everywhere yet; I do most of my testing on Firefox and Chrome. Let me know if you are able to reproduce this issue again anywhere.

I'll leave this issue open for now as a reminder to myself about the stringification of JSObjects.

haukex avatar Apr 28 '20 06:04 haukex