Closed Bug 947126 Opened 6 years ago Closed 5 years ago

Frequent 10.6 error devtools/styleinspector/test/browser_bug726427_csstransform_tooltip.js | uncaught exception - TypeError: getRuleViewProperty(...) is undefined at chrome://mochitests/co

Categories

(DevTools :: Inspector, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: intermittent-failure)

Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound opt test mochitest-browser-chrome on 2013-12-05 23:32:41 PST for push ca8e76cd1b16

slave: talos-r4-snow-009

possible regression from bug 726427 and the reason why we don't see as intermittent is that in some cases the mochitest failure on 10.6 is covered by a leak (Bug 946726)

https://tbpl.mozilla.org/php/getParsedLog.php?id=31547544&tree=Mozilla-Inbound

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/styleinspector/test/browser_bug726427_csstransform_tooltip.js | uncaught exception - TypeError: getRuleViewProperty(...) is undefined at chrome://mochitests/content/browser/browser/devtools/styleinspector/test/browser_bug726427_csstransform_tooltip.js:123
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/styleinspector/test/browser_bug726427_csstransform_tooltip.js | Test timed out
Investigating this issue now...

The test goes as follows:
- loads the inspector
- switches to the rule view
- enters a new css property: 'transform' with an invalid value: 'muchTransform(suchAngle)'
- tries to find the new property in the rule view UI
- asserts that the transform preview tooltip isn't shown on mouseover

It fails on osx 10.6 when trying to find the property in the rule view UI.
I can't reproduce this error locally and nothing comes to mind about how to fix it.
I've pushed a couple of code changes to try to try and get failures there and more information.
Assignee: nobody → pbrosset
(In reply to Carsten Book [:Tomcat] from comment #0)
> possible regression from bug 726427 and the reason why we don't see as
> intermittent is that in some cases the mochitest failure on 10.6 is covered
> by a leak (Bug 946726)

It is intermittent in fact. I've been trying to reproduce on 10.6 and it almost always works. See this latest try build for instance: https://tbpl.mozilla.org/?tree=Try&rev=9c7b7c47d482
I'm still trying to figure out why it sometimes fails.
It's a bit painful to investigate this issue as I don't have 10.6 and it only fails very rarely.
Nevertheless, I was able by adding lot's of logging and by re-launching many bc tests on try (see https://tbpl.mozilla.org/?tree=Try&rev=bbec5e7927be) to find out what caused the test to fail:

Instead of typing "transform" into the CSS property in the rule view, the text "transformansform" is being entered.
This happens after <TAB> is pressed (the test enters the word, char by char, using event simulation, and then simulates <TAB> to then enter the value).
I don't see why this would sometimes happen and sometimes not, but at least I may be able to re-write the test now that I know this.
I have just attached a new patch to bug 726427 with a more stable way to test, so this intermittent will go away when bug 726427 lands.

Having said that, we should keep this one open for the following root cause issue:

Consider the following mochitest-browser test case:

> function someTestFunction() {
>   let keyData = "transform".split("");
>   keyData.push("VK_TAB");
> 
>   // ...
>   // Click on the brace of a rule in the rule-view to focus a new inplace-editor
>   // ...
>   waitForEditorFocus(brace.parentNode, editor => {
>     typeKeySequence(keyData, () => {
>       // ...
>     });
>   });
> }
> 
> function typeKeySequence(sequence, cb, index=0) {
>   if (index === sequence.length) {
>     return cb();
>   }
>
>   EventUtils.synthesizeKey(sequence[index], {}, ruleView.doc.defaultView);
>   executeSoon(() => {
>     typeKeySequence(sequence, cb, index + 1);
>   });
> }

Intermittently, on osx 10.6, once `typeKeySequence` is done, we end up having the value: "transformansform" in the field, instead of "transform".

One such test failure is recorded in this log: https://tbpl.mozilla.org/php/getParsedLog.php?id=31683815&tree=Try&full=1
Open the log and search for "Typed key t".
Below that log line, you'll see logs for each key being typed, and below that you'll see log "Searching for css values for transformansform" which is printed by the inplace-editor when looking for completion values using: "domUtils.getCSSValuesForProperty(this.property.name)" (see http://mxr.mozilla.org/mozilla-central/source/browser/devtools/shared/inplace-editor.js#1032)
Assignee: pbrosset → nobody
(In reply to Patrick Brosset [:pbrosset] from comment #5)
> I have just attached a new patch to bug 726427 with a more stable way to
> test, so this intermittent will go away when bug 726427 lands.
> 
> Having said that, we should keep this one open for the following root cause
> issue:
> 
> Consider the following mochitest-browser test case:
> 
> > function someTestFunction() {
> >   let keyData = "transform".split("");
> >   keyData.push("VK_TAB");
> > 
> >   // ...
> >   // Click on the brace of a rule in the rule-view to focus a new inplace-editor
> >   // ...
> >   waitForEditorFocus(brace.parentNode, editor => {
> >     typeKeySequence(keyData, () => {
> >       // ...
> >     });
> >   });
> > }
> > 
> > function typeKeySequence(sequence, cb, index=0) {
> >   if (index === sequence.length) {
> >     return cb();
> >   }
> >
> >   EventUtils.synthesizeKey(sequence[index], {}, ruleView.doc.defaultView);
> >   executeSoon(() => {
> >     typeKeySequence(sequence, cb, index + 1);
> >   });
> > }
> 


> Intermittently, on osx 10.6, once `typeKeySequence` is done, we end up
> having the value: "transformansform" in the field, instead of "transform".

I believe that I've seen this (or a similar problem) locally, but never been able to consistently reproduce.  In the rule view, somtimes I'll start typing a word, and presumably because of some timing issue, the autocomplete will inject part of that word into the cursor location.  I can't describe exactly the error or STR, since it happens so infrequently.  Bug 913955 sounds like it is maybe related.
(In reply to TBPL Robot from comment #8)
> KWierso
> https://tbpl.mozilla.org/php/getParsedLog.php?id=33135461&tree=Fx-Team
> Ubuntu VM 12.04 x64 fx-team opt test mochitest-browser-chrome on 2014-01-16
> 16:33:48
> revision: af860898eb79
> slave: tst-linux64-ec2-388
> 
> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/browser/devtools/styleinspector/test/
> browser_bug726427_csstransform_tooltip.js | Test timed out

This is not the same failure, this one is tracked in bug 961004
Summary: Frequent 10.6 error TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/styleinspector/test/browser_bug726427_csstransform_tooltip.js | uncaught exception - TypeError: getRuleViewProperty(...) is undefined at chrome://mochitests/co → Frequent 10.6 error devtools/styleinspector/test/browser_bug726427_csstransform_tooltip.js | uncaught exception - TypeError: getRuleViewProperty(...) is undefined at chrome://mochitests/co
Component: Developer Tools: Style Editor → Developer Tools: Inspector
Blocks: 992211
Closing bugs where TBPLbot has previously commented, but have now not been modified for >3 months & do not contain the whiteboard strings for disabled/annotated tests or use the keyword leave-open. Filter on: mass-intermittent-bug-closure-2014-07
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.