search

rosshinkley / nightmare-inline-download

36 stars 8 forks source link

broken with nightmare 2.5.1 #3

Closed rmoriz closed 8 years ago

rmoriz commented 8 years ago

Hi,

seems not to work with recent nightmare release. Also tests failing when running against nightmare 2.5.1

  Nightmare download manager
    1) should be constructable
    downloads
      2) should download a file
      3) should error when download time exceeds request timeout
      4) should set a path for a specific download
      5) should cancel a specific download
      6) should ignore all downloads

  0 passing (2s)
  6 failing

  1) Nightmare download manager should be constructable:
     Error: done() invoked with non-Error: {"code":"MODULE_NOT_FOUND"}

  2) Nightmare download manager downloads should download a file:
     Error: done() invoked with non-Error: {"code":"MODULE_NOT_FOUND"}

  3) Nightmare download manager downloads should error when download time exceeds request timeout:
     Error: done() invoked with non-Error: {"code":"MODULE_NOT_FOUND"}

  4) Nightmare download manager downloads should set a path for a specific download:
     Error: done() invoked with non-Error: {"code":"MODULE_NOT_FOUND"}

  5) Nightmare download manager downloads should cancel a specific download:
     Error: done() invoked with non-Error: {"code":"MODULE_NOT_FOUND"}

  6) Nightmare download manager downloads should ignore all downloads:
     Error: done() invoked with non-Error: {"code":"MODULE_NOT_FOUND"}
rmoriz commented 8 years ago

loads with with 2.3.4, fails with 2.5.1: "failed: { code: 'MODULE_NOT_FOUND' }"

rosshinkley commented 8 years ago

Ah, oops. I think nightmare-inline-download uses a deprecated Electron module that no longer exists as of Electron 1.x. I'll take a look at this and fix it as soon as I can.

rosshinkley commented 8 years ago

Quick update: I fixed the module include, but it looks like Electron emits a did-fail-load anytime an attachment is set on the response. Looking into that as time permits.

rosshinkley commented 8 years ago

This behavior stretches back in to the history of Electron (I tested back to 0.35.0), and as such, was most likely broken with Nightmare 2.5.0 when .goto() was rewritten to fail fast when win.webContents hit a did-fail-load. I opened electron/electron#6054 to make sure the behavior is intentional. If so, I'll see if I can lobby for a patch to Nightmare to let aborted requests not be considered full failures.

rosshinkley commented 8 years ago

I should have verified that assertion as while I was on the right track, the above is not completely accurate. I just did some tinkering with Nightmare to see what it would take - I had forgotten there's now a built-in assertion for "page readiness" coming from did-finish-load. I'll have to think on this because this might (and probably will) have consequences if page readiness can be set from an aborted navigation.

rosshinkley commented 8 years ago

@rmoriz This should be fixed with nightmare 2.5.2 and nightmare-inline-download 0.2.1, which will be up shortly.