1734896 - (Puppeteer) Protocol error (Target.setDiscoverTargets): can't access property "documentTitle", this.browsingContext.currentWindowGlobal is null get title@chrome://remote/content/cdp/targets/TabTarget.jsm:108:5

Status: RESOLVED WONTFIX

(Remote Protocol :: CDP, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Puppeteer unit tests fail with this kind of error quite frequently in the last two days in the upstream CI for Windows. Maybe it is related to my changes for Fission, and we do only run the pup jobs on Linux. :/

Here the details of the failure:

https://github.com/puppeteer/puppeteer/runs/3832483753?check_suite_focus=true

     ProtocolError: Protocol error (Target.setDiscoverTargets): can't access property "documentTitle", this.browsingContext.currentWindowGlobal is null get title@chrome://remote/content/cdp/targets/TabTarget.jsm:108:5
_getTargetInfo@chrome://remote/content/cdp/domains/parent/Target.jsm:178:7
_onTargetCreated@chrome://remote/content/cdp/domains/parent/Target.jsm:187:29
setDiscoverTargets@chrome://remote/content/cdp/domains/parent/Target.jsm:82:12
execute@chrome://remote/content/cdp/domains/DomainCache.jsm:101:25
execute@chrome://remote/content/cdp/sessions/Session.jsm:64:25
onPacket@chrome://remote/content/cdp/CDPConnection.jsm:248:36
onMessage@chrome://remote/content/server/WebSocketTransport.jsm:89:18
handleEvent@chrome://remote/content/server/WebSocketTransport.jsm:71:14

Via https://github.com/puppeteer/puppeteer/pull/7658 the Firefox failures no longer block the CI results. It would be good to get this change reverted.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

The failure here happens when retrieving the tab's page title from within the TabTarget class. An instance of the class gets created when a new tab gets opened and the TabObserver emits the open event. To send out this internal event the TabObserver listens for the TabOpen event from the tab container.

As such there could be the following cases:

1. The opening tab is going to be closed immediately. As such we should check in TabObserver.onTabOpen that the tab is not closing before sending out the event.

2. The tab is visible but the page hasn't been loaded yet, or is going to be replaced due to the initial load of about:blank.

Now that we have Fission enabled the likelihood for trapping into case 2) is more likely now. Interesting is that this seems to happen exclusively on Windows in the Puppeteer CI. Maybe Fission is always enabled for that platform, while on Linux and MacOS we still do it selectively for now.

As such we should force Fission to be enabled in the Puppeteer launcher, and repeatedly run the broken test to hopefully get it more easily reproduced.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

With the following upstream CI job that does not have my patches from bug 1601245 it can be seen that most likely situation 2 is indeed causing the problem here:

https://github.com/puppeteer/puppeteer/runs/3857681559?check_suite_focus=true

The command Target.createTarget() results in an unexpected about:blank page to be returned.

I'll run some more jobs to get a better overview of the failures.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1601245

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:whimboo, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Igor]

Also got the error trying to reproduce this issue github/puppeteer

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

We are not going to fix that bug.