Open johnhawkinson opened 2 weeks ago
Thanks John. Any idea why this isn't breaking the extension for more people (I don't have any other reports?)
Historically it has not broken it for me, so I'm sure it relates to the exact order of cookies that I have right now, and probably some other bug that relates to why I lack an isFilingAccount
internal RECAP cookie, but disentagling that logic doesn't seem a good use of anyone's effort.
So, this probably only affects filing users and probably only somewhat randomly.
If it's helpful, here's the edited value of document.cookie
(which is passed to hasFilingCookie
by content_delegate.js) in my browser devtools from a page where RECAP is failing:
"_ga_CSLL4ZEK4L=redacted1; mpt_initial_referer=redacted2; _ga_83ZBSG354S=redacted3; KEY=redacted4"
But really, I think, just fix the missing guard and move on?
Seems simple enough. Thanks, I'll put it on Eduardo's backlog once he finishes a couple other things that are high priority.
The extension seems to be currently broken for me, probably specific to my cookie configuration. But it's also clear the code is broken. I get this error:
which is from this code in pacer.js:
which fails to guard
filingCookie
before calling.match()
.Prior to https://github.com/freelawproject/recap-chrome/commit/e2a07cf985e6c052f649f8325f083d473bacacb4 (Fri Nov 18 20:26:39 2022 -0400) this code properly guarded
filingCookie
beforematch()
.A similarly robust check should be applied here.
Not sure what the cookie pattern trigger is. I'll take my chocolate chips cooked on hot East Coat asphalt concrete with a few mirrors and maybe a lens, please.