1437992 - [wpt-sync] PR 8379 - Implement element_click test for wpt wdspec

Status: RESOLVED DUPLICATE of bug 1468146

(Testing :: geckodriver, enhancement, P5)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Testing webdriver element click spec.
Step 14.1.5 and 14.1.7 part 2 are incomplete.

https://w3c.github.io/webdriver/webdriver-spec.html#element-click

Comment 1

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=fcdcfb801f0f22078c5a1fe74ae28896a6316a91

Comment 2

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=1e80e2b2f734dc52cd5fd1593ca41bc34531caab

Comment 3

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

The following tests were disabled based on stability try push:
 webdriver/tests/element_click/element_click.py

Comment 4

[Andreas Tolfsen ❲:ato❳]

webdriver/tests/element_click/element_click.py only exists in
https://github.com/w3c/web-platform-tests/pull/8379 in upstream WPT.
Why do we file bugs on Firefox for PRs which have not yet landed?

Comment 5

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

To keep track of work that is about to be downstreamed to m-c from web-platform-tests. 

The bot opens a bug as soon as an upstream PR is opened. When the upstream checks pass, bot pushes to try. If the PR gets closed, bot closes the bug. If the PR is approved, and our try pushes look stable, we schedule it for landing on m-i.

Comment 6

[Andreas Tolfsen ❲:ato❳]

For the record, I don’t think this is particularly valuable
information to me as a Gecko developer.  An upstream PR of some
notability typically goes through many revisions until it is ready
for integration.  Also, not all PRs end up getting merged.

I would have thought that it is only when the PR is integrated in
WPT master and the bot tries to downstream it into central that we
would care about disabling it.

Comment 7

[James Graham [:jgraham]]

Well we don't actually do anything yet; the disabling doesn't happen until the patch is actually landed. But the point is to get ahead on PRs by having the results ready when they are integrated, and to give developers an early heads up about changes that they might like to examine in more detail before the upstream PR is complete.

It's probably possible to make the bot less verbose, but at the moment having a record of the activity in each bug is very useful for debugging.

Comment 8

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

So the original PR which this bug is referenced with was https://github.com/web-platform-tests/wpt/pull/8379.

But that got closed in favor of https://github.com/web-platform-tests/wpt/pull/11453.

So the code changes went in via the downstream merge as handled on bug 1468146.