Error in sonar analyzing this rule

[gemal]

after the update to 0.13.0
https://sonarwhal.com/scanner/c094bc44-a740-4f8b-a813-de82bd9c90d0

[alrra]

@gemal Thanks for opening this issue!

---

I tested the URL using the CLI, and it works with all connectors.

@sarvaje Maybe this is because of a timeout (jsdom takes quite a bit to complete)?

[molant]

@alrra the timeout shouldn't impact, we've had many sites with timeouts on axe.
We recently fixed a bug where a worker crash impacted the results of other crashes. It could be that we didn't fix it correctly or something else is going on. In any case, @sarvaje is investigating.

Thanks!

[sarvaje]

The line throwing the exception is this one.
The problem is that the manifest's content type is application/octet-stream. The requester is not setting the body.content.

Should we make something like this in the manifest-app-names rule?

const content = body.content || body.rawContent.toString()

or the content encoding has to be utf-8?

[molant]

@alrra you are the one that knows more about the manifest spec. What do you think?

[molant]

@gemal in the meantime if you want to see more results you can change your manifest encoding to utf-8 and serve it with the right mime type instead of application/octet-stream

[gemal]

according to https://developer.mozilla.org/en-US/docs/Web/Manifest:
Manifests should be served using the application/manifest+json MIME type. However, it is optional to do so.

[alrra]

or the content encoding has to be utf-8?

No.

The problem is that the manifest's content type is application/octet-stream.

In this type of cases, rules like this one should fail since the user basically serves binary data, so not valid JSON.

[dylanb]

Is there anything we can do from the axe-core side to help with this problem?

[molant]

Hi @dylanb,

For this specific issue the problem was in our code and #616 should fix it.

Nevertheless, the axe-core rule timeouts quite often with jsdom as you are already aware 😔

Do you know if there are any perf gains in axe-core's 3.x branch?
We could also try improving the VMs where we run sonar in the cloud see if that helps.
If you have any other ideas please let us know!

[dylanb]

@molant 3.0 does not contain any significant performance improvements although it does bypass the DOM for some operations so it might be faster in a JSDOM environment. you should try that out.

Out of pure interest, why do you use JSDOM rather than headless Chrome?

[molant]

Out of pure interest, why do you use JSDOM rather than headless Chrome?

Lack of time to get all the things we want done 😔
The idea is to let the user chose in the future what connector they want to use in the online service so that will eventually arrive. For now we decided to go with jsdom because it was easier to set up in the environment and requires less resources to run so we could scale up easier if needed.

Opened an issue to track that. I'll let you know how it goes.

[sarvaje]

@gemal You should be able to analyze your site without problems now:
https://sonarwhal.com/scanner/6f4035d9-9a6c-4583-a5d6-590cd119931f