RTCDTMFSender-ontonechange.https.html flaky in Win7 |
|||||
Issue descriptionexternal/wpt/webrtc/RTCDTMFSender-ontonechange.https.html is flaky on Win7, example: https://uberchromegw.corp.google.com/i/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/66589 Sample expected.txt diff: https://isolateserver.appspot.com/browse?namespace=default-gzip&digest=4d10b5bf1f2456fbd0b86ab8ce8fe44813d964ba&as=layout-test-results%5Cexternal%5Cwpt%5Cwebrtc%5CRTCDTMFSender-ontonechange.https-diff.txt Sample log from https://chromium-swarm.appspot.com/task?id=3be95cb30efbd710&refresh=10&show_raw=1: 21:31:31.553 2388 [3388/5752] external/wpt/webrtc/RTCDTMFSender-ontonechange.https.html failed unexpectedly (text diff) 21:31:31.547 7416 worker/6 external/wpt/webrtc/RTCDTMFSender-ontonechange.https.html failed: 21:31:31.548 7416 worker/6 text diff 21:31:32.641 7416 worker/6 external/wpt/webrtc/getstats.html output stderr lines: 21:31:32.641 7416 [7476:4276:0225/213131.541:ERROR:rtc_dtmf_sender_handler.cc(90)] WebRTCDTMFSenderHandlerClient not set. 21:31:32.641 7416 [7476:4276:0225/213131.559:ERROR:rtc_dtmf_sender_handler.cc(90)] WebRTCDTMFSenderHandlerClient not set. 21:31:32.641 7416 [5880:7012:0225/213132.289:ERROR:adm_helpers.cc(73)] Failed to query stereo recording. 21:31:32.641 7416 [5880:7012:0225/213132.581:WARNING:sctptransport.cc(498)] SctpTransport->ResetStream(1): stream not found.
,
Mar 13 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cfeb51ad2e375fd69ffc837669ff3f8f5af3f697 commit cfeb51ad2e375fd69ffc837669ff3f8f5af3f697 Author: Luna Lu <loonybear@chromium.org> Date: Tue Mar 13 15:12:18 2018 Mark external/wpt/webrtc/RTCDTMFSender-ontonechange.https.html flaky on Linux Bug: 816475 Change-Id: I8e79dd6d18b34aa46f0a64a15b4adfeb161c6544 Reviewed-on: https://chromium-review.googlesource.com/960566 Commit-Queue: Luna Lu <loonybear@chromium.org> Reviewed-by: Luna Lu <loonybear@chromium.org> Cr-Commit-Position: refs/heads/master@{#542801} [modify] https://crrev.com/cfeb51ad2e375fd69ffc837669ff3f8f5af3f697/third_party/WebKit/LayoutTests/TestExpectations
,
Mar 13 2018
From a brief look, this looks like a case of an event's handler not being called until an extra tone has slipped out of the tone buffer. This should only happen if the event handler is > 40 ms late, but that's not unthinkable at all. Either we need to rewrite the tests to be more robust, or we need to rewrite the implementation so that the tone buffer that is seen from the event handler is the tone buffer at the time of the event firing, not the tone buffer at the time of the event being handled.
,
Aug 13
,
Aug 13
,
Aug 13
Also disabled for the unified-plan virtual suite. Remember to check both after fixing.
,
Sep 7
,
Sep 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3f90035e2fac160d23309a96ef2cf465b29cebe4 commit 3f90035e2fac160d23309a96ef2cf465b29cebe4 Author: Harald Alvestrand <hta@chromium.org> Date: Mon Sep 10 14:55:55 2018 Implement DTMF [[ToneBuffer]] in the blink layer This CL makes the Blink layer keep a copy of the tone buffer and update it on insertDTMF and ontonechange events only; this makes it possible to expose the state of the tone buffer at the time the event is fired to the Javascript callback. It removes a queueing step inside the DTMF sender, because that queueing step destroyed the consistency. Bug: chromium:816475 Change-Id: I5aa68396299a67d6cea1e8a17d364f553514c291 Reviewed-on: https://chromium-review.googlesource.com/1213084 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Harald Alvestrand <hta@chromium.org> Cr-Commit-Position: refs/heads/master@{#589910} [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/content/renderer/media/webrtc/rtc_dtmf_sender_handler.cc [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/content/renderer/media/webrtc/rtc_dtmf_sender_handler.h [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/third_party/WebKit/LayoutTests/TestExpectations [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCDTMFSender-helper.js [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/third_party/blink/public/platform/web_rtc_dtmf_sender_handler_client.h [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/third_party/blink/renderer/modules/peerconnection/rtc_dtmf_sender.cc [modify] https://crrev.com/3f90035e2fac160d23309a96ef2cf465b29cebe4/third_party/blink/renderer/modules/peerconnection/rtc_dtmf_sender.h
,
Sep 10
,
Oct 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/65d72632bfa4a97fae0a317a91fca208773afa1e commit 65d72632bfa4a97fae0a317a91fca208773afa1e Author: Harald Alvestrand <hta@chromium.org> Date: Wed Oct 03 11:23:41 2018 Make DTMF tone change more deterministic Moved the scheduling of subsequent tones from the webrtc layer to the blink layer. Revised the tests to remove the chance to sneak in extra tonechange events when overriding a remaining tone buffer. Also change "approximate timing" to "at least this long". Bug: chromium:816475 Change-Id: Id91011600b61f43152c8fb896d72433ccb871c61 Reviewed-on: https://chromium-review.googlesource.com/c/1236337 Commit-Queue: Harald Alvestrand <hta@chromium.org> Reviewed-by: Henrik Boström <hbos@chromium.org> Cr-Commit-Position: refs/heads/master@{#596180} [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/WebKit/LayoutTests/TestExpectations [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCDTMFSender-helper.js [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCDTMFSender-ontonechange.https-expected.txt [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCDTMFSender-ontonechange.https.html [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/WebKit/LayoutTests/virtual/webrtc-wpt-unified-plan/external/wpt/webrtc/RTCDTMFSender-ontonechange.https-expected.txt [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/blink/renderer/modules/peerconnection/rtc_dtmf_sender.cc [modify] https://crrev.com/65d72632bfa4a97fae0a317a91fca208773afa1e/third_party/blink/renderer/modules/peerconnection/rtc_dtmf_sender.h
,
Oct 3
,
Oct 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c2776c27f8e028c9c1706dfbc17ab4780d293271 commit c2776c27f8e028c9c1706dfbc17ab4780d293271 Author: Harald Alvestrand <hta@chromium.org> Date: Fri Oct 05 13:09:57 2018 Revert "Implement DTMF [[ToneBuffer]] in the blink layer" This reverts commit 3f90035e2fac160d23309a96ef2cf465b29cebe4. Reason for revert: The original problem was solved using another approach, and this CL (which modifies the content layer) just adds complexity with no purpose. Original change's description: > Implement DTMF [[ToneBuffer]] in the blink layer > > This CL makes the Blink layer keep a copy of the tone buffer > and update it on insertDTMF and ontonechange events only; this > makes it possible to expose the state of the tone buffer at the > time the event is fired to the Javascript callback. > > It removes a queueing step inside the DTMF sender, because > that queueing step destroyed the consistency. > > Bug: chromium:816475 > Change-Id: I5aa68396299a67d6cea1e8a17d364f553514c291 > Reviewed-on: https://chromium-review.googlesource.com/1213084 > Reviewed-by: Guido Urdaneta <guidou@chromium.org> > Reviewed-by: Kentaro Hara <haraken@chromium.org> > Commit-Queue: Harald Alvestrand <hta@chromium.org> > Cr-Commit-Position: refs/heads/master@{#589910} Bug: chromium:816475 Change-Id: Iaee9fefa8a37e3c6c7256dacac0855f426601e0d Reviewed-on: https://chromium-review.googlesource.com/c/1264165 Reviewed-by: Henrik Boström <hbos@chromium.org> Reviewed-by: Harald Alvestrand <hta@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Harald Alvestrand <hta@chromium.org> Cr-Commit-Position: refs/heads/master@{#597087} [modify] https://crrev.com/c2776c27f8e028c9c1706dfbc17ab4780d293271/content/renderer/media/webrtc/rtc_dtmf_sender_handler.cc [modify] https://crrev.com/c2776c27f8e028c9c1706dfbc17ab4780d293271/content/renderer/media/webrtc/rtc_dtmf_sender_handler.h [modify] https://crrev.com/c2776c27f8e028c9c1706dfbc17ab4780d293271/third_party/blink/public/platform/web_rtc_dtmf_sender_handler_client.h [modify] https://crrev.com/c2776c27f8e028c9c1706dfbc17ab4780d293271/third_party/blink/renderer/modules/peerconnection/rtc_dtmf_sender.cc [modify] https://crrev.com/c2776c27f8e028c9c1706dfbc17ab4780d293271/third_party/blink/renderer/modules/peerconnection/rtc_dtmf_sender.h |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bugdroid1@chromium.org
, Feb 26 2018