Case ID not captured when users download from written opinion report

[mlissner]

Needs investigation. I suspect it's because we didn't capture the case number from a docket report page and thus never learned it. I don't know if we'll be able to find it another way, but we can try.

[johnhawkinson]

Also, in this case, it should be pretty easy to capture the case number.

We look like this:

Source like this:

<tr valign="top">
        <td><a href="/cgi-bin/DktRpt.pl?153992">1:13-cv-12092-RWZ </a><br><b>Phillips v. Equity Residential Management, L.L.C.</b></td>
        <td>11/01/2017</td>
        <td align="center"><a href="https://ecf.mad.uscourts.gov/doc1/09518360046" onclick="goDLS('/doc1/09518360046','153992','264','','','1','','');return(false);">95</a></td>
        <td>Judge Rya W. Zobel: ORDER entered denying  <a href="https://ecf.mad.uscourts.gov/doc1/09508351138" onclick="goDLS('/doc1/09508351138','153992','261','','','1','','');return(false);">94</a>   Motion  for entry of an indicative ruling  (Urso, Lisa)</td>
        <td><i>Office:</i> Boston<br><i>Case Flags:</i> <span style="color:Green">APPEAL</span><br><i>NOS:</i> Real Property: Other<br><i>Cause:</i> 28:1332 Diversity-Notice of Removal<br></td>
    </tr>

Specifically notice the <a> tag:

<a href="https://ecf.mad.uscourts.gov/doc1/09518360046" onclick="goDLS('/doc1/09518360046','153992','264','','','1','','');return(false);">95</a>

The 2nd parameter of the onclick goDLS() call is the case number. That's pretty obvious from inspection (just look two fields to the left at the DktRpt.pl link), but it's also clear from the unminified js. goDLS() is defined in https://ecf.mad.uscourts.gov/lib/core.js lines 88-89:

// lib/dls_url.js v6.2
function goDLS(k,g,b,e,a,c,i,l){var h="go_dls_url";var f; ...

but conveniently the comment leads us to the unminified version: https://ecf.mad.uscourts.gov/lib/dls_url.js

// $Header: /usr/local/cvsroot/district/web/lib/dls_url.js,v 6.2 2009/11/29 17:27:42 jpd Exp $
...
function goDLS(hyperlink, de_caseid, de_seqno, got_receipt, pdf_header, pdf_toggle_possible, magic_num, hdr) {

(Nice to know they still use CVS...warms the heart...)

---

Anyhow, the upshot is any <a> tag with a goDLS() handler ought to get the de_caseid handled by the extension.

So, I guess, content.js should not depend exclusively on this kind of thing:

var pacer_case_id = PACER.getCaseNumberFromUrls([document.referrer, url]);

which was always a problem (depending on the referrer? Ycch!). Although I'm not sure the best way to do this. I guess my JS ignorance is showing.

One way would be to modify the doc1 URLs to contain the case number, which seems icky (and visible to the ECF server, if it were to care, which it won't). Another would be to use js LocalStorage to save these mappings. Ugh, there's probably a better way.

[mlissner]

Yeah, we're using chrome.storage.local to store these mappings. It's basically the same thing as LocalStorage except it is for extensions.

The thing we need to do is to gather them from more locations than we currently do, and I agree it shouldn't be terribly hard to get them from the written opinions report and specifically from the goDLS function.

Nice find catching the un-minified version of goDLS. I hadn't caught that even though I'd reverse engineered that thing.

[johnhawkinson]

Yeah, we're using chrome.storage.local to store these mappings. It's basically the same thing as LocalStorage except it is for extensions.

Yeah, I see that now. But I'm acutely conscious of https://developer.chrome.com/apps/storage which notes:

chrome.storage is not a big truck. It's a series of tubes. And if you don't understand, those tubes can be filled, and if they are filled when you put your message in, it gets in line, and it's going to be delayed by anyone that puts into that tube enormous amounts of material.

I'm not sure what that means exactly, and the linked reference gives limits for the session storage but not the local storage. But the session storage limit of 512 items seems worrisome for this usage.

The callback can be called with chrome.runtime.lastError set but we don't seem to check for that, which seems like a future problem.

As I thought more about it last night it seemed like modifying the doc1 URL to contain the extra info was a better bet, and then extracting it afterwards. It seems cleaner even though it could let the ECF server interdict us.

Also, the screw case of a single document in multiple cases is not so rare as to be worth ignoring. It's easy to see something going wrong with that here.

[mlissner]

The Firefox docs say that Chrome allows 5MB and has an option for unlimited storage, and that Firefox is unlimited for the time being:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage/local

What I like about the local storage approach over the URL approach is that (1) it's already done, and (2), it should be more reliable. Once we get a case id to doc id mapping, we'll have it for the long haul no matter how somebody looks up the item.

As for the single doc in multiple cases, let's resolve that in another bug, if we can find an instance of it to work with.

[johnhawkinson]

The Firefox docs say that Chrome allows 5MB and has an option for unlimited storage, and that Firefox is unlimited for the time being:

Yeah, I was more concerned with the limits on number of items rather than size. Since there are cases with thousands of docket entries, it's not hard to see how having the plugin parse out case/doc mappings from one such page could run into issues.

As for the single doc in multiple cases, let's resolve that in another bug, if we can find an instance of it to work with.

For now, have an instance, from a NEF on Wednesday:

---

This is an automatic e-mail message generated by the CM/ECF system. Please DO NOT RESPOND to this e-mail because the mail box is unattended.
***NOTE TO PUBLIC ACCESS USERS*** There is no charge for viewing opinions.

U.S. District Court

California Northern District

Notice of Electronic Filing

The following transaction was entered on 11/1/2017 at 1:56 PM and filed on 11/1/2017

Case Name:	Regents of University of California et al v. United States Department of Homeland Security et al
Case Number:	3:17-cv-05211-WHA
Filer:
Document Number:	130

Docket Text:
ORDER GRANTING MOTION FOR LEAVE TO FILE AMICUS CURIAE BRIEF IN SUPPORT OF DEFENDANTS by Judge William Alsup granting (110) Administrative Motion leave to file amicus curiae brief in case 3:17-cv-05211-WHA.Associated Cases: 3:17-cv-05211-WHA, 3:17-cv-05235-WHA, 3:17-cv-05329-WHA, 3:17-cv-05380-WHA, 3:17-cv-05813-WHA(whalc1, COURT STAFF) (Filed on 11/1/2017)

Case Name:	State of California et al v. Department of Homeland Security et al
Case Number:	3:17-cv-05235-WHA
Filer:
Document Number:	57

Docket Text:
ORDER GRANTING MOTION FOR LEAVE TO FILE AMICUS CURIAE BRIEF IN SUPPORT OF DEFENDANTS by Judge William Alsup granting (110) Administrative Motion leave to file amicus curiae brief in case 3:17-cv-05211-WHA.Associated Cases: 3:17-cv-05211-WHA, 3:17-cv-05235-WHA, 3:17-cv-05329-WHA, 3:17-cv-05380-WHA, 3:17-cv-05813-WHA(whalc1, COURT STAFF) (Filed on 11/1/2017)

Case Name:	City Of San Jose v. Trump et al
Case Number:	3:17-cv-05329-WHA
Filer:
Document Number:	45

Docket Text:
ORDER GRANTING MOTION FOR LEAVE TO FILE AMICUS CURIAE BRIEF IN SUPPORT OF DEFENDANTS by Judge William Alsup granting (110) Administrative Motion leave to file amicus curiae brief in case 3:17-cv-05211-WHA.Associated Cases: 3:17-cv-05211-WHA, 3:17-cv-05235-WHA, 3:17-cv-05329-WHA, 3:17-cv-05380-WHA, 3:17-cv-05813-WHA(whalc1, COURT STAFF) (Filed on 11/1/2017)

Case Name:	Garcia et al v. United States of America et al
Case Number:	3:17-cv-05380-WHA
Filer:
Document Number:	41

Docket Text:
ORDER GRANTING MOTION FOR LEAVE TO FILE AMICUS CURIAE BRIEF IN SUPPORT OF DEFENDANTS by Judge William Alsup granting (110) Administrative Motion leave to file amicus curiae brief in case 3:17-cv-05211-WHA.Associated Cases: 3:17-cv-05211-WHA, 3:17-cv-05235-WHA, 3:17-cv-05329-WHA, 3:17-cv-05380-WHA, 3:17-cv-05813-WHA(whalc1, COURT STAFF) (Filed on 11/1/2017)

Case Name:	County of Santa Clara et al v. Trump et al
Case Number:	3:17-cv-05813-WHA
Filer:
Document Number:	28

Docket Text:
ORDER GRANTING MOTION FOR LEAVE TO FILE AMICUS CURIAE BRIEF IN SUPPORT OF DEFENDANTS by Judge William Alsup granting (110) Administrative Motion leave to file amicus curiae brief in case 3:17-cv-05211-WHA.Associated Cases: 3:17-cv-05211-WHA, 3:17-cv-05235-WHA, 3:17-cv-05329-WHA, 3:17-cv-05380-WHA, 3:17-cv-05813-WHA(whalc1, COURT STAFF) (Filed on 11/1/2017)

3:17-cv-05211-WHA Notice has been electronically mailed to:
...

[johnhawkinson]

I have a branch with preliminary support for parsing goDLS() calls at https://github.com/johnhawkinson/recap-chrome specifically: ~https://github.com/johnhawkinson/recap-chrome/commit/3c9239392be305e5176e3b0b6776ffdec19fb76f~ https://github.com/johnhawkinson/recap-chrome/commit/e51f6dacae51982e4c89862d357d4a6d78d2b5ec

but it blocks on server errors when dockets do not yet exist, so it is arguably not very useful.

So probably this needs to block on https://github.com/freelawproject/recap/issues/61.

although actually, I guess there are plenty of times when a docket does already exist in a written opinion report, so maybe it's worth going ahead with?

[johnhawkinson]

but it blocks on server errors when dockets do not yet exist, so it is arguably not very useful.

Specifically

           "status": 5,
           "upload_type": 3,
           "error_message": "Unable to find docket for item.",

I guess there are plenty of times when a docket does already exist in a written opinion report

Or not. Although the docket exists, the docket entry does not and that's sufficient to fail:

            "status": 5,
            "upload_type": 3,
            "error_message": "Unable to find docket entry for item.",

[mlissner]

This is now working. The problem remains that we don't get docket information for these cases before they upload stuff, but that'll be fixed, or at least addressed, in #61.