Closed Bug 1341199 Opened 7 years ago Closed 6 years ago

Intermittent devtools/client/responsive.html/test/browser/browser_device_change.js | value "Fake Phone RDM Test" should match an existing option. - Didn't expect undefined, but got it

Categories

(DevTools :: Responsive Design Mode, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell unknown])

this picked up around April 7th, on win7 opt/pgo.  trying to narrow this down:
https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=dt6%20win%20e10s&tochange=99572645ff7f9dab563cea956010469aed765e7f&fromchange=dc314cde29d390514937204a4413181b4a15f9b1&selectedJob=89358070

no changes to the file:
https://dxr.mozilla.org/mozilla-central/source/devtools/client/responsive.html/test/browser/browser_device_change.js?q=path%3Abrowser_device_change.js&redirect_type=single

05:53:09     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | Viewport should have height of 480px - 
05:53:09     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | UA should be set to Mozilla/5.0 (Windows NT 6.1; rv:55.0) Gecko/20100101 Firefox/55.0 - 
05:53:09     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | devicePixelRatio should be set to 1 - 
05:53:10     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | Touch events override should be disabled - 
05:53:10     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | Touch simulation button should be inactive. - 
05:53:10     INFO - Test viewport's device select label
05:53:10     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | Device Select value should be: no device selected - 
05:53:10     INFO - Waiting for event: 'device-changed' on [object Object].
05:53:10     INFO - Selecting Fake Phone RDM Test in .viewport-device-selector.
05:53:10     INFO - TEST-PASS | devtools/client/responsive.html/test/browser/browser_device_change.js | selector ".viewport-device-selector" should match an existing element. - 
05:53:10     INFO - TEST-INFO | started process screenshot
05:53:10     INFO - TEST-INFO | screenshot: exit 0
05:53:10     INFO - TEST-UNEXPECTED-FAIL | devtools/client/responsive.html/test/browser/browser_device_change.js | value "Fake Phone RDM Test" should match an existing option. - Didn't expect undefined, but got it
05:53:10     INFO - Stack trace:
05:53:10     INFO -     chrome://mochikit/content/browser-test.js:test_isnot:932
05:53:10     INFO -     chrome://mochitests/content/browser/devtools/client/responsive.html/test/browser/head.js:changeSelectValue:255
05:53:10     INFO -     chrome://mochitests/content/browser/devtools/client/responsive.html/test/browser/head.js:selectDevice:263
05:53:10     INFO -     chrome://mochitests/content/browser/devtools/client/responsive.html/test/browser/browser_device_change.js:null:46
05:53:10     INFO -     chrome://mochitests/content/browser/devtools/client/responsive.html/test/browser/head.js:addRDMTask/<:106
05:53:10     INFO -     Tester_execTest@chrome://mochikit/content/browser-test.js:752:9
05:53:10     INFO -     Tester.prototype.nextTest</<@chrome://mochikit/content/browser-test.js:672:7
05:53:10     INFO -     SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:791:59
05:53:53     INFO - Longer timeout required, waiting longer...  Remaining timeouts: 1
05:54:38     INFO - Not taking screenshot here: see the one that was previously logged
05:54:38     INFO - TEST-UNEXPECTED-FAIL | devtools/client/responsive.html/test/browser/browser_device_change.js | Test timed out - 
05:54:38     INFO - Removing tab.
05:54:38     INFO - Waiting for event: 'TabClose' on [object XULElement].
05:54:38  
05:54:38     INFO - Got event: 'TabClose' on [object XULElement].
05:54:38     INFO - Tab removed and finished closing
05:54:38     INFO - GECKO(3788) | MEMORY STAT | vsize 669MB | vsizeMaxContiguous 883MB | residentFast 190MB | heapAllocated 90MB
05:54:38  
   INFO - TEST-OK | devtools/client/responsive.html/test/browser/browser_device_change.js | took 90366ms



this looks like a failure here:
https://dxr.mozilla.org/mozilla-central/source/devtools/client/responsive.html/test/browser/browser_device_change.js?q=path%3Abrowser_device_change.js&redirect_type=single#46
Whiteboard: [stockwell needswork]
ok, this range shows two pgo commits where the top (most recent) has many failures, and the bottom (oldest) has no failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=dt6%20win%20e10s&tochange=07b054e43bb6ba983dce42c5600d29047a037644&fromchange=95f4f265acef2549cb6685d964db19608fc6656b

:jryans, anything in that range that would possibly cause this test to fail?
Flags: needinfo?(jryans)
(In reply to Joel Maher ( :jmaher) from comment #6)
> ok, this range shows two pgo commits where the top (most recent) has many
> failures, and the bottom (oldest) has no failures:
> https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-
> searchStr=dt6%20win%20e10s&tochange=07b054e43bb6ba983dce42c5600d29047a037644&
> fromchange=95f4f265acef2549cb6685d964db19608fc6656b
> 
> :jryans, anything in that range that would possibly cause this test to fail?

Unfortunately, I don't see any obvious suspects in that range.  Looking at autoland now, it seems like the failures have gone back down again?
Flags: needinfo?(jryans)
it is hard to determine if the failure rate has gone down- We had a weekend with very few commits as well as holiday for many on Friday as well as today.  I still see failures coming in- maybe we wait until next week to see if this persists.
Looking at the whole history of these failures in OF, I'd say there was an infrequent intermittent beginning around Feb 21 - perhaps related to the change to the test in bug 1331601? - which became more frequent around April 7, initially on autoland. Perhaps bug 1353045 is responsible for the change in frequency around April 7?
See Also: → 1331601, 1353045
this last week the failures are ~25, so I don't see a high volume- lets keep an eye on this and if any of the code nearby is being edited maybe debugging this a bit more might help.
there are almost no instances of this in the last 8 days.
Whiteboard: [stockwell needswork] → [stockwell unknown]
this failure is creeping up into our radar for investigating it- historically it magically gets better- :jryans, is there anyone who could look at this and see if there is something simple to do?
Flags: needinfo?(jryans)
(In reply to Joel Maher ( :jmaher) (UTC-5) from comment #25)
> this failure is creeping up into our radar for investigating it-
> historically it magically gets better- :jryans, is there anyone who could
> look at this and see if there is something simple to do?

Hmm, I don't think I'll have time in the immediate future, but perhaps :gl or :zerO?
Flags: needinfo?(zer0)
Flags: needinfo?(jryans)
Flags: needinfo?(gl)
Flags: needinfo?(gl)
Bulk priority update of open intermittent test failure bugs. 

P3 => P5

https://bugzilla.mozilla.org/show_bug.cgi?id=1381960
Priority: P3 → P5
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.