Closed Bug 881443 Opened 11 years ago Closed 7 years ago

Intermittent /html/content/test/test_video_wakelock.html | There was at least 200 milliseconds between the stop and the wakelock release

Categories

(Core :: Hardware Abstraction Layer (HAL), defect, P3)

Product:
Core
Component:
Hardware Abstraction Layer (HAL)
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox24 --- fixed
firefox25 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix
b2g-v1.1hd --- fixed
b2g-v1.2 --- unaffected
b2g-v1.3 --- unaffected
b2g-v1.3T --- unaffected
b2g-v1.4 --- disabled
b2g-v2.0 --- disabled

People

(Reporter: RyanVM, Assigned: kanru)

References

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on B2G Debug][leave open])

Attachments

(1 file)

Patch
546 bytes, patch
baku
: review+
Details | Diff | Splinter Review 
https://tbpl.mozilla.org/php/getParsedLog.php?id=23965913&tree=Mozilla-Inbound

Ubuntu VM 12.04 mozilla-inbound opt test mochitest-1 on 2013-06-10 09:50:02 PDT for push 1c15d9da2ae6
slave: tst-linux32-ec2-316

10:08:47     INFO -  141338 INFO TEST-START | /tests/content/html/content/test/test_video_wakelock.html
10:08:47     INFO -  141339 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the target == screen
10:08:47     INFO -  141340 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the screen - no paused
10:08:47     INFO -  141341 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the target == screen
10:08:47     INFO -  141342 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the screen - no paused
10:08:47     INFO -  141343 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | There was at least milliseconds between the stop and the wakelock release
10:08:47     INFO -  141344 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the target == screen
10:08:47     INFO -  141345 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the screen - paused
10:08:47     INFO -  141346 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the target == screen
10:08:47     INFO -  141347 INFO TEST-PASS | /tests/content/html/content/test/test_video_wakelock.html | Video element locked the screen - paused
10:08:47     INFO -  141348 ERROR TEST-UNEXPECTED-FAIL | /tests/content/html/content/test/test_video_wakelock.html | There was at least 200 milliseconds between the stop and the wakelock release
10:08:47     INFO -  141349 INFO TEST-END | /tests/content/html/content/test/test_video_wakelock.html | finished in 1663ms
Justin, do you have any ideas about this by chance? Otherwise, can you suggest someone else who might?
Flags: needinfo?(justin.lebar+bug)
kanru and baku have worked on this code; maybe they can help.
Flags: needinfo?(kchen)
Flags: needinfo?(justin.lebar+bug)
Flags: needinfo?(amarchesini)
Can't reproduce locally. Maybe we are running into https://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp#2159?

The HTMLVideoElement::WakeLockCreate and HTMLVideoElement::WakeLockRelease share the same implementation so calling WakeLockCreate equals to WakeLockRelease if the condition matches.
Flags: needinfo?(kchen)
Presumably this is related to bug xxx as well.
See Also: → 879214
I'm looking into this.
Maybe we shouldn't use the 'progress' event. I suspect it's already too late when it's fired. The wakelock.ogv is only 260 milliseconds

https://tbpl.mozilla.org/?tree=Try&rev=03431c9f6f01
Attached patch Patch — — Splinter Review 
Use 'playing' event instead of 'progress'.

The test video is so short that I suspect when we receive the first 'progress' event the video has already finished and released the wakelock.

The try run looks greenish.
Attachment #796574 - Flags: review?(amarchesini)
Attachment #796574 - Attachment is patch: true
Kan-Ru, can bug 879214 take a similar fix?
Assignee: nobody → kchen
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox26: --- → affected
Comment on attachment 796574 [details] [diff] [review]
Patch

Review of attachment 796574 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm, thanks!
Attachment #796574 - Flags: review?(amarchesini) → review+
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #66)
> Kan-Ru, can bug 879214 take a similar fix?

Yeah, I think so.
Keywords: checkin-needed
Looks like we're still hitting this :(
status-firefox26: fixed → affected
Flags: needinfo?(amarchesini) → needinfo?(kchen)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #72)
> Looks like we're still hitting this :(

Uh-oh.. this is not good :(
Flags: needinfo?(kchen)
Looks like it had stopped?
Let's wait a bit longer. Judging by the history of the bug, it's never been horribly frequent.
Closing inactive keywords:intermittent-failure bugs where the TBPLbot has previously commented and the test isn't marked as disabled; filter on orange-cleanup-201401.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Reopening based on the last ~30-odd TBPL comments. :-\
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to :Gijs Kruitbosch from comment #113)
> Reopening based on the last ~30-odd TBPL comments. :-\

My assumption is that the current version of this failure amounts to "B2G debug emulator tests are really slow". I'm wondering if this is even worth trying to fix or if we should just disable the test there and move on with life.
Flags: needinfo?(kchen)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #115)
> (In reply to :Gijs Kruitbosch from comment #113)
> > Reopening based on the last ~30-odd TBPL comments. :-\
> 
> My assumption is that the current version of this failure amounts to "B2G
> debug emulator tests are really slow". I'm wondering if this is even worth
> trying to fix or if we should just disable the test there and move on with
> life.

Yep :(

Could we disable the test just for the B2G debug emulator?
Flags: needinfo?(kchen) → needinfo?(ryanvm)
Sure thing.

https://hg.mozilla.org/integration/b2g-inbound/rev/6a7f5df97834
Flags: needinfo?(ryanvm)
Whiteboard: [test disabled on B2G Debug][leave open]
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/ead66a556654

Going to leave this open on the off chance that we ever get faster machines to run the debug emulator on.
status-b2g-v1.2: --- → unaffected
status-b2g-v1.3: --- → unaffected
status-b2g-v1.3T: --- → unaffected
status-b2g-v1.4: --- → disabled
status-b2g-v2.0: --- → disabled
status-firefox26: affected → ---
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Status: REOPENED → RESOLVED
Closed: 10 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: