Closed mlissner closed 1 year ago
@mlissner It's odd but the receipt page says that the document number is 97. Here's a screenshot:
I noticed that the case number is also different. I'm trying to get document ten from case 19-1083 but the link is redirecting to document 97 from case 19-1081.
I checked the docket 19-1081 and the document is also listed there (as docket entry 97).
I reviewed the HTML of the docket entry in both docket reports and the href attribute of the anchor is the same, so I think this issue happens when the same document( with the same pacer_doc_id) is listed in two different dockets using different entry numbers.
the extension is showing this weird behavior too, so I disabled it to check how PACER handles these cases and noticed that the only difference in the receipt pages is the value populated in the caseId
hidden field, for document 97 the caseId is 13514 but for document 10 the caseId is 13516
I think we can fix this issue if the extension adds the caseId parameter to the href attribute of the anchors in the docket report so the href attribute will look like the following:
https://ecf.cafc.uscourts.gov/docs1/01301660046?caseId=13514 https://ecf.cafc.uscourts.gov/docs1/01301660046?caseId=13516
Let me know what you think
Hm, here are three experiments:
STR:
Result in PACER:
Expected result:
STR:
Result in PACER:
Expected result:
STR:
Results in PACER:
PASS!
It seems like we're doing something that is messing up the links, eh?
Yes. We're changing the default behavior of the links in PACER to avoid opening tabs. The current implementation of the extension removes the default onClick event from the document links and it's using the href attribute instead.
This href attribute is the same in docket number 19-1083
and in docket number 19-1801
and that's the cause of this issue. It seems like PACER needs more information to identify the docket entry associated with the document.
Makes sense. I guess the onclick sends the PACER case ID as well? If so, I guess we're pretty safe just mirroring that as you proposed.
Yes, It does. The onClick envent submits a form that has the caseId
and docId
as hidden inputs. Here's the HTML of the form and the JS for the onClick event:
<form name="doDocPostURLForm" method="post" target="_blank" action="TransportRoom">
<input name="servlet" type="hidden" value="ShowDoc">
<input name="dls_id" type="hidden" value="">
<input name="caseId" type="hidden" value="">
<input name="dktType" type="hidden" value="dktPublic">
</form>
<script type="text/javascript">
function doDocPostURL(dls, caseIdStr){
document.doDocPostURLForm.dls_id.value = dls;
document.doDocPostURLForm.caseId.value = caseIdStr;
document.doDocPostURLForm.submit();
return false;
}
</script>
Great. Please proceed with your fix. Glad we caught this in dev!
The fix I proposed will work for the extension ( the second experiment will pass) but I think the first experiment will still fail because CL's "Buy On PACER" links add a parameter called caseid
in the query string but the name of the hidden input is caseId
so the link from CL might redirect to the wrong receipt page. Here's an example:
the following links should take you to item 10 from docket number 19-1083:
caseId
parameter)caseid
instead of caseId
)Cool. I just submitted a PR to fix this in CL and put you as the reviewer, @ERosendo.
I deleted all cookies, then purchased document ten from this docket:
https://www.courtlistener.com/docket/8034892/nvlsp-v-united-states/
It said it got uploaded (hell yeah!), but it didn't show up in the docket, so I went to look at the RECAP processing queue. The matching document is here:
https://www.courtlistener.com/api/rest/v3/recap/7378058/?court=cafc
Which returns:
I wondered why it was "unable to find docket entry for item", and the answer is that it somehow thinks that the document number is 97. That's weird! It should be document number 10.
Back in PACER, it looks like the document number also shows as 97:
That must be getting parsed from somewhere it shouldn't be?