Closed Bug 1499957 Opened 1 year ago Closed 9 months ago

Green up wpt infrastructure directory on fennec

Categories

(Testing :: web-platform-tests, defect, P3)

Version 3
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: KWierso, Unassigned)

References

Details

One failure:

/infrastructure/testdriver/actions/elementTiming.html
  FAIL TestDriver actions: element timing - assert_array_equals: property 1, expected 150 but got 149
actions<@http://web-platform.test:8000/infrastructure/testdriver/actions/elementTiming.html:53:34
Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1561:20
Test.prototype.step_func_done/<@http://web-platform.test:8000/resources/testharness.js:1601:17



During the actual test run, there's this, if it helps:

 2:39.43 TEST_START: /infrastructure/testdriver/actions/elementTiming.html
 2:40.59 INFO {'actions': [{u'type': u'pointer', u'actions': [{u'y': 0, u'x': 0, u'type': u'pointerMove', u'origin': {'element-6066-11e4-a52e-4f735466cecf': u'2bcf36dd-4aa1-47de-8e0c-ecaaf8a6d2d8', 'chromeelement-9fc5-4b51-a3c8-01716eedeb04': u'2bcf36dd-4aa1-47de-8e0c-ecaaf8a6d2d8'}}, {u'button': 0, u'type': u'pointerDown'}, {u'button': 0, u'type': u'pointerUp'}, {u'y': 0, u'x': 0, u'type': u'pointerMove', u'origin': {'element-6066-11e4-a52e-4f735466cecf': u'36dbbe1b-b326-4ff8-bc35-c4d999cabca8', 'chromeelement-9fc5-4b51-a3c8-01716eedeb04': u'36dbbe1b-b326-4ff8-bc35-c4d999cabca8'}}, {u'button': 0, u'type': u'pointerDown'}, {u'button': 0, u'type': u'pointerUp'}], u'parameters': {u'pointerType': u'mouse'}, u'id': u'1'}]}
 2:40.78 TEST_END: Test OK. Subtests passed 0/1. Unexpected 1
Ccing James and Ato because James mentioned that this sounds like something similar to something Ato worked on or was working on.
Any ideas?
Flags: needinfo?(ato)
It’s quite hard to make out from the bug report, or indeed the test,
what this is trying to test.  I’ve never worked with testdriver
before, but I’m assuming it’s testing that the DOM manipulations
(making div#test2 flow as part of the document) propagate before
the second half of the actions chain proceeds to click it.  Then
it asserts that the click occurred on the in-view centre point of
div#test2.

If div#test2 is a 100x100 px square and its left hand corner starts
where div#test1 ends (that is at margin-left 100px), in-view centre
point of this square is calcaulated according to
https://w3c.github.io/webdriver/#dfn-center-point:

  rectangle = DOMRect { x: 0, y: 100, width: 100, height: 100, top: 100, right: 100, bottom: 200, left: 0 }

  left = max(0, min(0, 0 + 100))
  right = min(1192, max(0, 0 + 100))
  top = max(0, min(100, 100 + 100))
  bottom = min(855, max(100, 100 + 100))

  x = floor((0 + 100) / 2.0)
  y = floor((100 + 200) / 2.0)

This means we arrive at the click coordinate (50,150) which is what
the test is expecting.

I landed some changes for Marionette to support the flooring part
of the algorithm about two weeks ago (but after this bug was filed)
in https://bugzilla.mozilla.org/show_bug.cgi?id=1499360, but I can’t
see how that can affect the outcome of x/y, since no odd numbers
are involved.

I can point you to where the click is done internally in Marionette:
https://searchfox.org/mozilla-central/rev/7c0a5e2aefd29b5b56923bc9fbc1180fc488b33c/testing/marionette/interaction.js#136-189

I hope this helps! (-:
Flags: needinfo?(ato)
Priority: -- → P3

Mass-closing fennec wpt bugs as we're not going to be running wpt against fennec in the near future.

Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.