1646293 - Page.navigate hangs for error pages

Status: RESOLVED INVALID

(Remote Protocol :: CDP, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Currently our navigation code hangs when a navigation request has a valid URL syntax but causes an error page (network, certificate issue) to pop-up. In such a case the load event is never fired.

When running Chrome I can see a Network.loadingFailed event being emitted. We need the same and once implemented our navigation code in Page.jsm (parent) can handle that event.

  puppeteer:protocol SEND ► {"sessionId":"EFB0083DE641A0335F7475DD2F052562","method":"Page.navigate","params":{"url":"xyz://www","frameId":"ACD31DC658E8879432F30AD27817DDF1"},"id":16} +1ms
  puppeteer:protocol ◀ RECV {"method":"Network.requestWillBeSent","params":{"requestId":"AB2A9E01F42A2E8DE360B64DA42FACD0","loaderId":"AB2A9E01F42A2E8DE360B64DA42FACD0","documentURL":"xyz://www","request":{"url":"xyz://www","method":"GET","headers":{},"mixedContentType":"none","initialPriority":"VeryHigh","referrerPolicy":"strict-origin-when-cross-origin"},"timestamp":349848.791357,"wallTime":1592380268.811915,"initiator":{"type":"other"},"type":"Document","frameId":"ACD31DC658E8879432F30AD27817DDF1","hasUserGesture":false},"sessionId":"EFB0083DE641A0335F7475DD2F052562"} +3ms
  puppeteer:protocol ◀ RECV {"method":"Network.loadingFailed","params":{"requestId":"AB2A9E01F42A2E8DE360B64DA42FACD0","timestamp":349848.792098,"type":"Document","errorText":"net::ERR_ABORTED","canceled":true},"sessionId":"EFB0083DE641A0335F7475DD2F052562"} +2ms
  puppeteer:protocol ◀ RECV {"id":16,"result":{"frameId":"ACD31DC658E8879432F30AD27817DDF1","loaderId":"AB2A9E01F42A2E8DE360B64DA42FACD0","errorText":"net::ERR_ABORTED"},"sessionId":"EFB0083DE641A0335F7475DD2F052562"} +1ms

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The bug as reported is actually not valid. When I checked with Puppeteer I missed to add a try/catch around the call to page.goto(), and as such the browser didn't close. The only bit which is missing here is indeed the Network.loadingFailed event. But implementation is on the other bug.