Open Bug 1549475 Opened 7 months ago Updated 13 days ago

[meta] Page.navigate

Categories

(Remote Protocol :: Page, task)

task
Not set

Tracking

(Not tracked)

REOPENED

People

(Reporter: ato, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug, )

Details

(Keywords: meta, Whiteboard: [method=Page.navigate])

No description provided.
Depends on: protocdp, 1543095
Keywords: meta
Whiteboard: [method=Page.navigate]
Depends on: 1549786
Depends on: 1560294

Closing as all dependencies appear to be done

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED

There are parameters we don’t implement which we don’t have bugs for,
so it’s probably wise to leave these meta bugs open in perpetuity.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Mind filing those bugs, so that it is clear from the dependency tree what still has to be done?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #3)

Mind filing those bugs, so that it is clear from the dependency
tree what still has to be done?

We have a meta bug for each command and event, but beyond that it’s
hard to tell upfront how the implementation work will be structured.

In some cases it makes sense to implement command parameters
individually as one, logical chunk (for example Page.navigate’s
ignoreCache
). But frequently you might cover several parameters,
if not all, when you add support for a command. It’s also not given
that we want to implement everything that CDP does, so I think this
by necessity has to be approached on a case-by-case basis.

In the case of Page.navigate, there’s referrer, transitionType,
and frameId, but we haven’t run into cases in the Gutenberg- or
Puppeteer test suites that require them yet.

Status: REOPENED → RESOLVED
Closed: 4 months ago4 months ago
Resolution: --- → FIXED

I assume closing this bug was not the expected thing to do. As you say while everything we need to get puppeteer-mvp done has been implemented, some parts haven't been done yet. As such we should keep this bug open but remove it as blocker for puppeteer-mvp.

The remaining work to do is actually related to the return object, which doesn't have the loaderId and errorText implemented. Everything else seems to be done meanwhile.

No longer blocks: puppeteer-mvp
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Can you please point to some data that loaderId and errorText
is consumed by Puppeteer?

I believe this is the metric we use to determine if a bug be closed,
which was at the request of product management to keep track
of progress on this project.

Flags: needinfo?(hskupin)

For the MVP and specifically the Gutenberg tests the following bug are necessary:

Both have direct dependencies to bug 1539202 setup. So we don't need the dependency setup again for this meta bug. Also puppeteer example will get direct dependencies.

As such this bug stays open for the remaining work to do maybe in next year.

No longer blocks: puppeteer-examples
Flags: needinfo?(hskupin)
You need to log in before you can comment on or make changes to this bug.