Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In debug mode, commented out script tags are still being run #787

Closed
samreid opened this issue Aug 12, 2019 · 25 comments
Closed

In debug mode, commented out script tags are still being run #787

samreid opened this issue Aug 12, 2019 · 25 comments
Assignees

Comments

@samreid
Copy link
Member

samreid commented Aug 12, 2019

Steps to reproduce:

  1. Build Energy Skate Park
  2. Run the debug version, like http://localhost/energy-skate-park/build/phet/energy-skate-park_all_phet_debug.html

Observe an error like so:

query.yahooapis.com/v1/public/yql?q=use%22http://davidbau.com/encode/srandom.xml%22;select*from%20srandom%20where%20nbytes%3D@nbytes;&format=json&diagnostics=false&callback=Math.seedrandom&nbytes=512:1 Failed to load resource: net::ERR_NAME_NOT_RESOLVED
urandom:1 Failed to load resource: the server responded with a status of 503 ()

image

seedrandom is putting this code in the HTML:

//   <script src="http://bit.ly/srandom-512"></script>
//                             Seeds using physical random bits downloaded
//                             from random.org.
//
//   <script src="https://jsonlib.appspot.com/urandom?callback=Math.seedrandom">
//   </script>                 Seeds using urandom bits from call.jsonlib.com,
//                             which is faster than random.org.

And somehow those scripts are running. The bit.ly script redirects to :

view-source:https://query.yahooapis.com/v1/public/yql?q=use%22http://davidbau.com/encode/srandom.xml%22;select*from%20srandom%20where%20nbytes%3D@nbytes;&format=json&diagnostics=false&callback=Math.seedrandom&nbytes=512

@jessegreenberg
Copy link
Contributor

Here is the script that is being loaded, can see it is no longer commented out in the source. Text coloring makes it look like it is respecting the closing script tag on line 34465.
image

@SaurabhTotey
Copy link
Member

Is that a JS file or an HTML file? May it be that HTML comments use <!-- and --> instead of //?

@samreid
Copy link
Member Author

samreid commented Aug 12, 2019

Here's a simplified HTML example:

<head></head>
<body>
<script type="application/javascript">
  console.log( 'hello' );
  // Usage:
  //   <script src=http://davidbau.com/encode/seedrandom-min.js></script>
console.log('bye');
</script>

</body>

image

@samreid
Copy link
Member Author

samreid commented Aug 12, 2019

This problem seems to be noted in the top answer in https://stackoverflow.com/questions/28259389/how-to-put-script-in-a-javascript-string

@jessegreenberg
Copy link
Contributor

Nice, replacing </script> with <\/script> as recommended in that issue makes the problem go away.

@jessegreenberg
Copy link
Contributor

So we could escape for these lines manually. But is there a way that the build could insert escapes if we find a closing tag within a javascript comment?

@jonathanolson
Copy link
Contributor

The minification process does escape these, we provide inline_script: true to uglify's output options. Maybe we could consider minification for debug builds (but with beautified output and without stripping assertions or mangling)?

@samreid
Copy link
Member Author

samreid commented Sep 9, 2019

Tagging for developer meeting to decide how to proceed.

@samreid samreid removed their assignment Sep 9, 2019
@Denz1994
Copy link
Contributor

Denz1994 commented Sep 19, 2019

Discussed at dev meeting: 09/19/19

We will proceed with this comment here will handle escaping, but would get rid of line comments.

If debug builds are used just for assertions then having comments may be helpful. We can use stack trace to track relevant code to the assertion or search for code snippet globally in code.

@Denz1994 is assigned and will reference @jonathanolson or @samreid if needed.

@jessegreenberg
Copy link
Contributor

jessegreenberg commented Oct 29, 2020

This came up again in phetsims/sherpa#80 during an RC of ESP. Adding the blocks-publication label.

@pixelzoom
Copy link
Contributor

I'm assuming that this does not block publication of the dev test for Natural Selection, for phetsims/natural-selection#251. @ariel-phet please correct me asap if that's incorrect.

Denz1994 added a commit that referenced this issue Nov 2, 2020
@Denz1994
Copy link
Contributor

Denz1994 commented Nov 2, 2020

The debugMinifyOptions in buildRunnable.js was adjusted to minify and beautify the debug builds as suggested above. Assertions are still included in these builds. I tested a few debug builds in energy-skate-park, energy-skate-park-basics, and fluid-and-pressure-flow. The errors have ceased in the console, as described in phetsims/sherpa#80. Assigning to @jonathanolson for a final review.

@samreid
Copy link
Member Author

samreid commented Nov 2, 2020

I compared the build version before and after the changes, it noticed that after the changes, the debug version is missing all of the code comments.

Is there a way to run uglify so that it only runs "inline_script"?

@jessegreenberg
Copy link
Contributor

Thanks @KatieWoe - I discussed this issue with @jonathanolson over slack and he reviewed saying that the changes are safe to proceed with for a publication so I am cherry-picking them to the energy-skate-park-1.1 branch of chipper. Also removing the blocks publication label.

@jessegreenberg
Copy link
Contributor

Over slack @jonathanolson said that the changes are safe, but if people are relying on comments in debug files then we should look into restoring them. Adding to developer meeting to see if anyone is relying on comments in the debug build.

@KatieWoe
Copy link

I am not seeing these errors in ESP rc3 anymore.

@jessegreenberg jessegreenberg removed their assignment Nov 19, 2020
@samreid
Copy link
Member Author

samreid commented Nov 19, 2020

@zepumph: It's not important to me that the code comments are in the debug version.
@Denz1994: It's more important that the assertions are not stripped out
@samreid: Preferably the code comments would remain in.
@zepumph: Yes, but it is rare to look at a debug version for context--we try to move to master quickly to reproduce the problem
@chrisklus: I agree
@jonathanolson: But what about problems where a PhET-iO client produces a problem where we cannot easily replicate the problem?
@samreid: I think the debug version should be used for more than just assertions--would be nice to allow users to take a look around and see comments in the debug file.. Why not just remove this bad line from numeric-1.2.6.js?
@zepumph: It would be even better if we could auto detect this kind of problem. We could reach out to that developer and ask if they could remove it?

@samreid: I'll see if there's a new version without that.

@samreid
Copy link
Member Author

samreid commented Nov 23, 2020

@zepumph: We could reach out to that developer and ask if they could remove it?
@samreid: I'll see if there's a new version without that.

numeric.js has not been maintained since 2012.

@samreid
Copy link
Member Author

samreid commented Nov 23, 2020

I tried putting output:{comments:'all'}, but it increased the production minify time from

Debug minification complete: 13309ms (4082787 bytes)

to

Debug minification complete: 73311ms (6822163 bytes)

which is too long, in my opinion. Also, the formatting is not very readable:

image

samreid added a commit that referenced this issue Nov 23, 2020
samreid added a commit that referenced this issue Nov 23, 2020
… </script> tags in html comment blocks. See #787."

This reverts commit cb2e957
@samreid
Copy link
Member Author

samreid commented Nov 23, 2020

I manually escaped the closing tags in the comments of numeric-1.2.6.js, and reverted the changes to the minification process. I noticed this speeds up the builds by about 13 seconds.

Before:

Debug minification complete: 13309ms (4082787 bytes)

After:

Debug minification complete: 0ms (6721183 bytes)

This also fixes the formatting:

image

And there are no HTTP requests when starting the debug version of energy skate park. The main part this solution is missing is how to prevent this kind of problem from being reintroduced. Some ideas for that:

(a) (lazy, low effort) wait until we see this problem again
(b) (manual effort) add a manual step to the RC process where you launch the debug version and check the console. This could be done once per version, once per month, once per year depending on our tolerance for this problem.
(c) (eager, automated) add an automatic step to the RC process which automatically launches the sim and checks the console. This would take a few hours to build with puppeteer, and would slow down builds by a few seconds.
(d) (eager, automated) add a precommit hook that prevents us from committing this kind of problem again (our default lint rules don't work on 3rd party code)

@Denz1994 can you please review and comment?

@samreid samreid assigned Denz1994 and unassigned samreid Nov 23, 2020
@KatieWoe
Copy link

Noting that option b is already (basically) standard for at least one rc in a testing round. I run the debug sim with a fuzz test and the console open for ~10 minutes while testing something else on another device, so that I can catch assertions that might happen.

@samreid samreid assigned samreid and unassigned Denz1994 Jan 28, 2021
@samreid
Copy link
Member Author

samreid commented Jan 29, 2021

Since (b) is basically in place, I think we can close this issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants