Last Comment Bug 759521 - WebTelephony: investigate test failures for outgoing calls
: WebTelephony: investigate test failures for outgoing calls
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Device Interfaces (show other bugs)
: Trunk
: ARM Gonk (Firefox OS)
: -- normal (vote)
: mozilla16
Assigned To: Hsin-Yi Tsai [:hsinyi]
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: 756607
  Show dependency treegraph
 
Reported: 2012-05-29 14:47 PDT by Philipp von Weitershausen [:philikon]
Modified: 2012-06-14 02:45 PDT (History)
5 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
Patch: update test_outgoing_reject.js (1.94 KB, patch)
2012-06-05 02:03 PDT, Hsin-Yi Tsai [:hsinyi]
no flags Details | Diff | Splinter Review
Patch (v2) : update test_outgoing_reject.js (1.83 KB, patch)
2012-06-05 02:32 PDT, Hsin-Yi Tsai [:hsinyi]
no flags Details | Diff | Splinter Review
Patch (v3): update test scripts (4.86 KB, patch)
2012-06-08 02:28 PDT, Hsin-Yi Tsai [:hsinyi]
no flags Details | Diff | Splinter Review
Patch (v4) (3.08 KB, patch)
2012-06-08 04:03 PDT, Hsin-Yi Tsai [:hsinyi]
philipp: review+
Details | Diff | Splinter Review
Patch (v5) (3.07 KB, patch)
2012-06-13 03:47 PDT, Hsin-Yi Tsai [:hsinyi]
no flags Details | Diff | Splinter Review

Description Philipp von Weitershausen [:philikon] 2012-05-29 14:47:04 PDT
Some of the outgoing call tests in bug 756607 fail and had to be disabled. We should investigate if they're testing faulty assumptions, our implementation is busted, or the emulator is messing things up somehow.
Comment 1 Dietrich Ayala (:dietrich) 2012-05-31 20:47:00 PDT
Not a blocker - a test harness problem.
Comment 2 Hsin-Yi Tsai [:hsinyi] 2012-06-04 19:54:16 PDT
After discussing with Price about the error-notifying mechanism and some experiments, "error" event is never fired in the situation of dialing a bad number. That's the reason why "test_outgoing_badNumber.js" in bug 756607 always fails. 

Actually, the events of dialing a bad number are the same as those of dialing a legal number.
Comment 3 Hsin-Yi Tsai [:hsinyi] 2012-06-04 20:24:28 PDT
Regarding the failure in "test_outgoing_busy.js" there are two reasons: 
(1) WebTelephony never fires "busy" event because the call state never reaches nsIRadioInterfaceLayer::CALL_STATE_BUSY in our implementation. 
(2) the emulator command "gsm busy" can be used only if the current call state is "waiting". In the test script, the call state right before "gsm busy" is unknown.
Comment 4 Hsin-Yi Tsai [:hsinyi] 2012-06-05 02:03:41 PDT
Created attachment 630106 [details] [diff] [review]
Patch: update test_outgoing_reject.js

"gsm cancel" cannot be used to cancel a call with unknown state. We need to wait until the connection is established, then "gsm cancel" works fine.
Comment 5 Hsin-Yi Tsai [:hsinyi] 2012-06-05 02:20:51 PDT
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3)
> Regarding the failure in "test_outgoing_busy.js" there are two reasons: 
> (1) WebTelephony never fires "busy" event because the call state never
> reaches nsIRadioInterfaceLayer::CALL_STATE_BUSY in our implementation. 

I filed Bug 761533 for this failure.
Comment 6 Hsin-Yi Tsai [:hsinyi] 2012-06-05 02:32:02 PDT
Created attachment 630112 [details] [diff] [review]
Patch (v2) : update test_outgoing_reject.js

addressed some nits
Comment 7 Hsin-Yi Tsai [:hsinyi] 2012-06-08 02:28:27 PDT
Created attachment 631317 [details] [diff] [review]
Patch (v3): update test scripts

Minor modifications are applied according to the investigation in bug 757587. Thanks.
Comment 8 Hsin-Yi Tsai [:hsinyi] 2012-06-08 04:03:26 PDT
Created attachment 631341 [details] [diff] [review]
Patch (v4)

Updated.

When I was working on bug 761533, I found that we might miss something for call error event. Seems nothing incorrect in Philipp's test script 'test_outgoing_basNumber.js' So, I added 'test_outgoing_basNumber.js', which had been deleted in attachment 631317 [details] [diff] [review], back. Thanks.
Comment 9 Hsin-Yi Tsai [:hsinyi] 2012-06-08 04:31:50 PDT
In Bug 761533, i will revisit call error handling function. So, I will keep investigate test_outgoing_badNumber and test_outgoing_busy there.
Comment 10 Philipp von Weitershausen [:philikon] 2012-06-11 15:50:33 PDT
Comment on attachment 631341 [details] [diff] [review]
Patch (v4)

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

Good sleuthing! r=me with readability nit addressed.

::: dom/telephony/test/marionette/test_outgoing_reject.js
@@ +75,5 @@
> +function waitForCancel() {
> +  runEmulatorCmd("gsm list", cmdCallback);
> +}
> +
> +function cmdCallback(result) {

Not sure why you didn't inline this... You don't refer to it anywhere else, so it just clutters up readability, I think.
Comment 11 Hsin-Yi Tsai [:hsinyi] 2012-06-11 18:58:33 PDT
(In reply to Philipp von Weitershausen [:philikon] from comment #10)
> Comment on attachment 631341 [details] [diff] [review]
> Patch (v4)
> 
> Review of attachment 631341 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Good sleuthing! r=me with readability nit addressed.
> 
> ::: dom/telephony/test/marionette/test_outgoing_reject.js
> @@ +75,5 @@
> > +function waitForCancel() {
> > +  runEmulatorCmd("gsm list", cmdCallback);
> > +}
> > +
> > +function cmdCallback(result) {
> 
> Not sure why you didn't inline this... You don't refer to it anywhere else,
> so it just clutters up readability, I think.
Thanks for the comment. Will provide a new patch with the comment addressed. :)
Comment 12 Hsin-Yi Tsai [:hsinyi] 2012-06-13 03:47:56 PDT
Created attachment 632628 [details] [diff] [review]
Patch (v5)

addressed nit in Comment #10. Thanks!
Comment 13 Ryan VanderMeulen [:RyanVM] 2012-06-13 18:17:38 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/a958b5ab2f48
Comment 14 Ed Morley [:emorley] 2012-06-14 02:45:18 PDT
https://hg.mozilla.org/mozilla-central/rev/a958b5ab2f48

Note You need to log in before you can comment on or make changes to this bug.