🐛 Fix duplicate resource URL issues with snapshot method

[Robdel12]

What is this?

The queue mapping was not using the normalized URL for the root resource. This meant if the URL included a hash or just a port it would send the same normalized URL twice (which the API will reject).

Will fix #641

[wwilsman]

🎮

[patricknelson]

I'm watching issue #641. I just cloned, yarn and yarn build this latest version and still get errors.

Basically, web fonts aren't loading at all. I'm guessing maybe this is a different problem? See:

[percy:core:discovery] Encountered an error processing resource: http://static.PRIMARY_LOCAL_DOMAIN/static/theme/fonts/helvetica-neue/light/688ab72b-4deb-4e15-a088-89166978d469.ttf (0ms)
[percy:core:discovery] Error: Protocol error (Network.getResponseBody): No resource with given identifier found
    at C:\Users\patnelson\Desktop\cli\packages\core\dist\session.js:58:16
    at new Promise (<anonymous>)
    at Session.send (C:\Users\patnelson\Desktop\cli\packages\core\dist\session.js:56:12)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Object.request.response.buffer (C:\Users\patnelson\Desktop\cli\packages\core\dist\network.js:273:20)
    at async Network.onRequestFinished (C:\Users\patnelson\Desktop\cli\packages\core\dist\discovery.js:82:32)
    at async Session._handleLoadingFinished (C:\Users\patnelson\Desktop\cli\packages\core\dist\network.js:296:5) (0ms)

Where PRIMARY_LOCAL_DOMAIN is a domain mapped to 127.0.0.1 (actual test going to that domain, subdomains also mapped to 127.0.0.1).

[Robdel12]

Hey @patricknelson! If you could provide a reproduction that would be helpful. My guess would be there's an issue with the non-standard URL (no TLD). Once we have something we can look at with a reproduction we can figure out a fix 😃

[patricknelson]

Actually, I just swapped out PRIMARY_LOCAL_DOMAIN with an actual website.vm.something.net domain that we use internal for local development purposes that I didn't want to advertise to the public internet (where website and something represent specific things I'm hiding 😬).

However, I totally get the need for steps for reproduction. I'll see what I can do and try to submit a separate issue if I can. Already have a ticket open with support as well (613003).

[Robdel12]

Gotcha, yeah scrubbing logs will confuse us 🤪 We see some interesting come through, so I wasn't going to assume it was scrubbed haha

And yeah, support tickets just make their way to me anyways. Feel free to share to directly with me, that way we can talk without a middle party :p

[patricknelson]

Trying to debug this on my own @Robdel12. Narrowed this down to some kind of problem with it not being able to load fonts on a separate domain, i.e. if testing example.com and loading fonts from static.example.com it will fail (even if the domain is allowed and all the CORS headers/etc are still set properly).

That's why I'd love to have access to the DevTools in the Chrome instance to see if maybe something is configured incorrectly on my end and, if not, I can provide an easier way to repro. It's complicated to reproduce because it would require you to properly setup multiple domains and ensure you have the correct headers and etc. Thanks!

[patricknelson]

Quick update (so you don't waste time trying to answer):

1. I hacked the code so that the --remote-debugging-port was a predictable 9222
2. I did an early return on close in browser.js and in page.js to prevent the page from closing
3. Went to chrome://inspect/#devices to inspect the page and found the problem

In this case the error was relating to CORS since we have a super restrictive policy on the allowed headers during OPTIONS preflight. But basically, x-vqa wasn't allowed by CORS:

Access to font at 'http://static.example.com/some-font-file.woff' from origin 'http://example.com' has been blocked by CORS policy: Request header field x-vqa is not allowed by Access-Control-Allow-Headers in preflight response.

Resolution: Maybe should submit a new issue to get detailed console log output, especially useful in situations like these during --debug in order more easily surface errors like these (especially CORS which can be tricky!).