Private URL breaks online scanner

[getify]

I just ran the web scanner against my site, and it just fails with a bunch of errors that are all invalid, as if it couldn't read the site at all -- basic, simple things like not finding the <meta charset="utf-8"> that is most definitely in the very top of my site's HTML:

Here are my test results:

NOTE: I'm deliberately withholding the site URL from this issue because it's not publicly announced/available yet, but happy to share privately if useful.

Actually, it's strange, because on my phone the scanner reports these issues as 28 errors, but from my desktop browser, as you can see, it reports them as 28 warnings. And yet it says:

There was an error and we were only able to partially complete the scan.

BUT, then down below, the report shows only errors, not warnings:

Lastly, when I try to click the "perform another scan" link provided in this report page, I get taken to an error page like this:

---

Unfortunately, I am not able currently to run the CLI tool on my site. I am only able, from where I'm at right now, to run the web scanner. That's why I'm reporting these issues with the online scanner and report.

[molant]

Hi @getify,

I think the problem you are running into is that the website that you are analyzing breaks jsdom and thus you are only getting partial results (those that do not rely on jsdom). It could be for a variety of reasons that hopefully will get fixed once we get #163 and #1223 done

If you could send me the url and the scan result permalink via DM on twitter (I have DMs open and I use the same username) we can take a look to confirm, and see if @sarvaje's current work on jsdom passes this website.

I think you've also found an issue with the scanner where we are counting errors executing tests in different ways (warnings in the top, "error" in the sections). I've opened #1257 to track that.

RE the CLI, if I understood correctly is not an issue with the tool in itself but rather your current circumstances, correct? When you have the time please try it. Also the default configuration for the CLI is slightly different than the online version so you might have different results (and you might want to try with the chrome connector instead of jsdom which is the default one).

Thanks for taking the time to report this issue!

[molant]

Got the url and I can confirm that it breaks jsdom. This is part of the --debug output:

  hint:utils:appinsights Sending exception to Application Insights: indexDB +11s
  hint:utils:appinsights Sending pending data to Application Insights +0ms
Unhandled rejection promise:
    uri: undefined
    message: undefined
    stack:
undefined

@sarvaje I assigning this to you. Let me know when you want to investigate the url so I can share it with you.

[sarvaje]

@molant send me the url please.

[sarvaje]

Hi @getify. I found the cause of the problem.

Long story short: the feature tests file is throwing an unhandled exception that is capture by webhint and it terminate the analysis, returning error.

jsdom is able to capture an unhandled exception when the scripts is "synchronous", but the feature tests script use promises so, after run the code "synchronously" the file run ok so jsdom doesn't capture any error, but after a few milliseconds, the script throws an unhandled exception because 'indexDB' is not supported in jsdom.

I have open an issue in jsdom jsdom/jsdom#2346.

[getify]

the feature tests file is throwing an unhandled exception that is capture by webhint and it terminate the analysis, returning error.

What is the unhandled exception? Almost everything is wrapped in a try..catch or a promise constructor, so there shouldn't be exceptions. Or do you mean an unhandled promise rejection?

[sarvaje]

Or do you mean an unhandled promise rejection?

an unhandled promise rejection

[getify]

ok, i've tweaked the feature-test code so it shouldn't allow an unhandled promise rejection anymore. but i'm very curious why the tool is sensitive to those? unhandled promise rejections happen all the time in pages.

[sarvaje]

the issue is not in webhint itself, is in jsdom, they current implementation is not able to capture an unhandled promise rejection.

You can follow or join to the conversation here: jsdom/jsdom#2346 :)

[getify]

Fixing the unhandled rejection in my feature-tests unblocked me so I can get a more complete report.

I am however seeing a handful of peculiar errors like this:

I'm wondering if those come from the fact that I have <script type="text/html">..</script> elements inlined in my markup -- I use these to include some simple HTML templates -- and maybe that's another breaking thing for JSDOM?

[molant]

Those happen in axe and no-vulnerable-javascript-libraries, the ones that inject JS in the context of the page to get the data.

@sarvaje can you take a look tomorrow? From the error message is seems like the scripts are executed but an error is thrown and for whatever reason it's not captured correctly. Usually they timeout if the page is too complex but this error is completely different (and new).

[getify]

I think this part of my OP might have been missed:

Lastly, when I try to click the "perform another scan" link provided in this report page, I get taken to an error page like this:

[molant]

@getify you are right. I just opened webhintio/webhintio.github.io#497 to track it.

Thanks!

[molant]

I just saw that someone beat me to it in webhintio/webhintio.github.io#496

[getify]

Those happen in axe and no-vulnerable-javascript-libraries, the ones that inject JS in the context of the page to get the data.

Did those get fixed just today?

I just re-ran my scan, and those errors are gone. The only thing I changed since the last time was that I fixed the SSL-Labs thing so that I get an A+ score instead of a B. I wouldn't have thought that would have any impact on the Axe and no-vuln checks.

[sarvaje]

Did those get fixed just today?

No, I didn't have time to take a look yet.

[sarvaje]

ok, I'm not able to reproduce the error "Executing script 'undefined'. Please try with another connector"

[getify]

Yeah, I know, it seems to have been "fixed" because I improved my SSL-Labs score from "B" to "A+", so that error no longer occurs. That's the only thing I changed since the last time I saw those errors happening. Bizarre that they would be related at all, but it seems like they were.

[sarvaje]

I improved my SSL-Labs score from "B" to "A+"

Ahhh, maybe it is more related that we think. I remember that yesterday I had some SSL Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE with the package request and your URL, so maybe the errors executing the scripts were related with that.

[sarvaje]

Can we close these issue?
The "perform another scan" issue is fixed webhintio/webhintio.github.io#496 but not deployed yet.
The Execution script error can't be reproduce anymore since the improve of the SSL-Labs score.
The problem counting warnings and errors is fixed.

[molant]

@alrra is working on the fix that will unblock webhintio/webhintio.github.io#496. I'd like us to wait until then.

[alrra]

Site was deployed.