1710921 - NS_ERROR_INTERCEPTION_FAILED on medicare.gov

Status: RESOLVED WORKSFORME

(Core :: DOM: Service Workers, defect, P3)

Description

[Dennis Schubert [:denschub]]

We've received a webcompat issue about the search form at https://www.medicare.gov/medical-equipment-suppliers/?redirect=true not working correctly if the zip code 32162 is used (and probably all others, but I'm copying that just in case)

On inspection, the "invalid zip" error is just a general fallback message for whenever the request to the search endpoint fails. In the devtools, I can see the request to https://www.medicare.gov/api/procedure-price-lookup/dme/api/v1/address/lookup?zipcode=32162 failing with NS_ERROR_INTERCEPTION_FAILED

Unfortunately, I don't see the service worker in question in about:debugging, and I see no additional errors in the browser toolbox either, so I'd appreciate some help here.

Comment 1

[Jens Stutte [:jstutte]]

I tried this in current Nightly and now I get:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bam.nr-data.net/resources/1/642335d5b5?a=145488977&sa=1&v=1123.df1c7f8&t=Unnamed%20Transaction&rst=16274&ref=https://www.medicare.gov/medical-equipment-suppliers/&st=1637918714895&ptid=64352472-0001-be2b-8047-017d5b90455b. (Reason: CORS request did not succeed). Status code: (null).

Karl, that looks more like a real site error and we are just stricter than other browsers?

Comment 2

[Karl Dubost💡 :karlcow]

I also get one, but different.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://pc-cmsgov-collect.tealiumiq.com/cmsgov/medicare-www/2/i.gif. (Reason: CORS request did not succeed). Status code: (null).

1. in about:config, if I set content.cors.disable: true this is working.
2. I still get error messages about CORS in the console.
3. I get a new error message Uncaught SyntaxError: missing ] after element list utag.sync.js:9:8note: [ opened at line 9, column 0utag.sync.js:9
4. resetting the cors setting to false
5. Trying again. https://www.medicare.gov/medical-equipment-suppliers/results?location=32162 (WORKING)
6. Going to https://www.medicare.gov/medical-equipment-suppliers/?redirect=true
7. new error messages such as Error: no slsRequestToken, see fetchUser thunk main.c7b6953b.chunk.js:1:20419 which seems generated because one of the request is considered unauthenticated. But this happens on Edge and Safari too.
8. Still Entering the postcode and having the right results.

So I guess CORS forbade the setting of something (cookie, caching of a piece of code, etc?) than then the site was not able to work. Once the parameter has been set the site is "working" even with CORS activated.

On Edge Blink. I get this too.

(index):1 
        
       A parser-blocking, cross site (i.e. different eTLD+1) script, https://tags.tiqcdn.com/utag/cmsgov/medicare-www/prod/utag.sync.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.

On Safari, yet another strange message.

AES-CBC and AES-CTR do not provide authentication by default, and implementing it manually can result in minor, but serious mistakes. We recommended using authenticated encryption like AES-GCM to protect against chosen-ciphertext attacks.
quantum-medicare.js:57:296

but everything is working.

so it is messy, but indeed like Dennis I'm not sure what is the source.

AH! After trying a couple of times it worked. (reload and/or shift+reload) Do you have the same thing (on desktop)

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Note that shift-reload bypasses ServiceWorker interception. (Although also note that the ServiceWorker at https://www.medicare.gov/medical-equipment-suppliers/service-worker.js uses clients claim, so it will try and take over existing pages whenever it can... but when bypasses I guess it won't try and do that.)

Also, it seems like the default ETP tracking protection behavior for me on Nightly thinks the https://bam.nr-data.net/ URL is a tracker. If I turn that off things seem to work fine?

Comment 4

[Dennis Schubert [:denschub]]

ni? myself to check if this is still an issue.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jstutte, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Jens Stutte [:jstutte]]

I assume this was meant to go to you, Thomas?

Comment 7

[Thomas Wisniewski [:twisniewski]]

I seem to be able to enter a zip code just fine now on the site, maybe it has been fixed? Dennis, does it also work for you?

Comment 8

[Dennis Schubert [:denschub]]

I can't.