Open Bug 1453214 Opened 2 years ago Updated 6 hours ago
_inspector _highlighter-cssshape _04 .js | Circle center successfully moved -
This intermittent used to be failing quite rarely, but started to spike quite impressively over the past 4 days. Apparently on windows and linux debug mostly. Razvan, any idea why that would be?
Priority: P5 → P2
Attachment #9016927 - Flags: review?(jmaher) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/c86bcd5caf4d Disable Bug 1453214 for frequent failures on windows and linux64 r=jmaher
There are 60 failures in the last 7 days. They occur on 56 linux32 (opt) 3 osx-10-10 (opt) 1 macosx64-nightly (opt) Recent failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=207472885&repo=mozilla-inbound&lineNumber=2808 jmaher: I see that this was disabled on linux64. Should it be disabled on linux32 as well? Thank you!
:ebalazs_ please go ahead and disable on linux32, basically os == linux :)
Attachment #9019666 - Flags: review?(jmaher) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/547f834561c3 Disable browser_inspector_highlighter-cssshape_04.js on linux. r=jmaher
Looking at the screenshot in one of the test failures: https://taskcluster-artifacts.net/F9tJCH63QVGsaPVVb6r6fw/0/public/test_info/mozilla-test-fail-screenshot_ixiDkC.png This is very odd. The #circle element is selected, but instead of seeing a circle clip-path value in the CSS rules-view, there's a polygon instead. Also the property has a green bar next to it meaning that the rules-view thinks the property was edited. I'm thinking perhaps the test does not wait for the right events, and selects the #circle element too fast, before the shape path editor has finished editing the previous shape, and therefore the CSS rules for #circle gets edited to a polygon. Unfortunately, I did not manage to make this test fail locally, but I'm fairly certain it's a timing problem, and we need to make the test wait a bit more during each action. For now, it waits for the ruleview-changed event, maybe it should also wait for something else.
I've looked more at this today. We indeed aren't waiting for the right events in this test. Whenever a shape is changed in the page, it results in several different events being fired, some of them fired twice. For instance, property-value-updated is fired twice. I have not been able to understand why that is (this event is normally triggered after a shape is changed, and I was able to confirm that this happened only once), but the fact is that because it does, we need the test to wait for these 2 events every time it changes a shape. Otherwise we run the risk of some unwanted code running after the test has moved on to doing other things. And that probably explains this intermittent. So I would advise surrounding the shape editing code with: // Have to wait for 2 of these events. const onPropertyValueUpdated = waitForNEvents(view, "property-value-updated", 2); ... simulate the various mouse events here ... await onPropertyValueUpdated; I don't have time to create a patch for this, but someone should because this test fails very frequently, and then push to try with many retriggers to see if things work better.
Flags: needinfo?(pbrosset) → needinfo?(rcaliman)
You need to log in before you can comment on or make changes to this bug.