Open Bug 1356214 Opened 5 years ago Updated 3 years ago
TEST-UNEXPECTED-FAIL | devtools/client/inspector/rules/test/browser
_rules _edit-display-grid-property .js | Uncaught exception - at chrome://mochitests/content/browser/devtools/client/inspector/rules/test/browser _rules _edit-display-grid-property .js:40
This occurs when the mochitest devtools browser chrome is run on the 16.04 docker image Try result shows that this is the only failure on this new configuration
Relevant Error Info.: Uncaught exception - at chrome://mochitests/content/browser/devtools/client/inspector/rules/test/browser_rules_edit-display-grid-property.js:40 - TypeError: editor is undefined
Summary: TEST-UNEXPECTED-FAIL | devtools/client/inspector/rules/test/browser_rules_edit-display-grid-property.js | Uncaught exception - at chrome://mochitests/content/browser/devtools/client/inspector/rules/test/browser_rules_edit-display-grid-property.js:40 - Typ → TEST-UNEXPECTED-FAIL | devtools/client/inspector/rules/test/browser_rules_edit-display-grid-property.js | Uncaught exception - at chrome://mochitests/content/browser/devtools/client/inspector/rules/test/browser_rules_edit-display-grid-property.js:40
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P3
This is the only failure in devtools keeping us from moving the tests from 12.04 to 16.04 :pbro- is there anyone that can look at this or things we can do to try to fix this ourselves? Any direction would be good.
Debugging this further https://treeherder.mozilla.org/logviewer.html#?job_id=95487834&repo=try&lineNumber=2225 returns a HTMLSpanElement instead of a HTMLTextAreaElement [task 2017-04-29T19:04:51.840017Z] 19:04:51 INFO - Selecting the node for '#grid' [task 2017-04-29T19:04:51.840921Z] 19:04:51 INFO - container [task 2017-04-29T19:04:51.851399Z] 19:04:51 INFO - [object HTMLSpanElement] [task 2017-04-29T19:04:51.853497Z] 19:04:51 INFO - Toggling ON the CSS grid highlighter from the rule-view. [task 2017-04-29T19:04:51.854433Z] 19:04:51 INFO - Edit the 'grid' property value to 'block'. [task 2017-04-29T19:04:51.855331Z] 19:04:51 INFO - Waiting for event: 'focus' on [object HTMLSpanElement]. [task 2017-04-29T19:04:51.856746Z] 19:04:51 INFO - Clicking on editable field to turn to edit mode [task 2017-04-29T19:04:51.857879Z] 19:04:51 INFO - Got event: 'focus' on [object HTMLSpanElement]. [task 2017-04-29T19:04:51.858895Z] 19:04:51 INFO - onFocus [task 2017-04-29T19:04:51.860053Z] 19:04:51 INFO - [object Object] [task 2017-04-29T19:04:51.861141Z] 19:04:51 INFO - Editable field gained focus, returning the input field now [task 2017-04-29T19:04:51.862195Z] 19:04:51 INFO - editable.ownerDocument.activeElement [task 2017-04-29T19:04:51.863459Z] 19:04:51 INFO - [object HTMLSpanElement]
(In reply to Joel Maher ( :jmaher) from comment #4) > :pbro- is there anyone that can look at this or things we can do to try to > fix this ourselves? Any direction would be good. Hey Joel, sorry for the delay replaying here. I know that Mavericks is looking into this, we've been discussed over the past couple of days on IRC, I'm trying to help him investigate the issue. I'll look at little bit into it today to see if I can help more.
I did investigate a bit more and found an issue. I'm very surprised that this never failed before, and I'm not sure why it would start showing only with the 16.04 image, but anyway, this thing needs fixing: in this test, we use the focusEditableField test helper function, defined in devtools\client\inspector\test\shared-head.js focusEditableField. This function clicks on an element and waits for it to become an input field. Indeed, there are many places in devtools where, if you click on a value, that value becomes editable. This is what happens in this test, where we click on a css value inside the Rules view. Now, focusEditableField listens for the focus event on the parent node and whenever it happens, signals to the test that its done. The problem with that is that there are in fact 2 focus events going on here: On for when the click focuses the css value in the Rules view, and a second one when the input field appears and gets focused. With the current implementation of focusEditablefield, we return after the first focus event, without fully waiting for the input field to be ready. So there's a chance for a race condition here. We need to fix focusEditableField so it waits for the right focus event, on the right target, and only then returns. Mavericks: are you still investigating this? Does this help? Do you want to proceed with a fix? Or would you rather me post a patch for this?
Thank you for the detailed explanation pbro Please do post the patch
I've been sending various patches to try using the patch in bug 1319807 to run tests on Ubuntu 16.04, no luck so far. The fix discussed in comment 7 makes perfect sense and I really thought it would solve this, but it seems from the logs I've added that the click on the element in the rules-view doesn't trigger the inplace editor like it should. The only other way is to test this on VM locally. I don't have one currently. Joel: feel free to disable this test if bug 1319807 is urgent in the meantime.
thanks :pbro, I will disable this one test as we can then get all of the devtools on 16.04 and leave this bug open for tracking.
I am disabling this in bug 1319807, should I leave this open for further investigation?
Sure. I'll attach my current patch as a starting point.
Here's the fix I was considering for this intermittent. As said earlier it avoids a race condition that we should have really fixed before. But it doesn't do the trick on the new ubuntu docker image. On this specific environment, the click on the property value does happen, and we receive a focus event on the right span element, but that click doesn't make the inplaceEditor turn into edit mode and show its input field. So we never receive a second focus event inside the input field, like we do on other platforms.
You need to log in before you can comment on or make changes to this bug.