Skip to content
This repository was archived by the owner on Dec 4, 2017. It is now read-only.

Conversation

@tOkeshu
Copy link

@tOkeshu tOkeshu commented Jan 16, 2013

Automatically reject calls if we're already in another call on mobile.
Improve the UI to provide a meaningful warning for the caller.

static/mobile.js Outdated
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need the audioOnly variable in here, so maybe move that test and early return just after the "var data = " ... line?

Automatically reject calls if we're already in another call on mobile.
Improve the UI to provide a meaningful warning for the caller.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't most (of not all) of these rules duplicated with #callAnswer?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coding style: please fix the indent here.

@fqueze
Copy link

fqueze commented Jan 23, 2013

From IRC:
Here's a situation where the behavior isn't what I would expect (not sure if it existed before your changes or not).
A and B are on desktop (social api), C is on the mobile page. A attempts to call C (the accept/reject buttons appear on C's mobile page). Then B attempts to call C. B sees immediately the "caller is busy" message. C clicks "Reject".
Expected result: A sees the "call rejected" message.
Actual result: A still has the "Calling..." message

a random guess is that the reject message could be going to B instead of A when C clicks "reject"

Not sure what the conclusion of the IRC discussion was, so I'm pasting my IRC comments here for future reference.

I really like these changes otherwise :).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This timer needs to be cancelled when the user closes the floating window by hand. Otherwise, it may execute if the user starts another call with the same contact; that's what caused the bug I mentioned at #37 (comment)

@fqueze
Copy link

fqueze commented Jan 25, 2013

  • With 2 desktop (SocialAPI) clients A and B, if A calls B, B has an accept/reject floating window, then if A closes his floating window, B now has "The call has been closed" above the accept/reject buttons. The behavior I would expect would be: hide the accept/reject buttons, and display a "The call has been canceled" message.
  • Clicking on the "reject" button of the floating window displays "The call has been closed" on the other side. Shouldn't it say "the call has been rejected"?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants