New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 618036 link

Starred by 1 user
Status: WontFix
Owner:
█ zijiehe@chromium.org
Last visit > 30 days ago
Closed: Sep 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

SESSION_REJECTED error type needs to be handled by WebApp

Project Member Reported by zijiehe@chromium.org, Jun 7 2016 
Version: M53, up to 96e2312ade0d985d9b2c4877f54dfacd7939bc9f
OS: Independent

TODO: Handle ErrorCode::SESSION_REJECTED in WebApp.

WebApp does not handle ErrorCode::SESSION_REJECTED. So now in JingleMessage, we send AUTHENTICATION_FAILED instead.

Comment 1 by zijiehe@chromium.org, Jun 7 2016

Labels: OS-Chrome OS-Linux OS-Mac OS-Windows

Comment 2 by jamiewa...@chromium.org, Jun 7 2016

Owner: zijiehe@chromium.org
Status: Assigned (was: Untriaged)
Based on discussion at triage, I think we only generate this in response to "permission denied" type scenarios. I think we should just rename the enum to something more appropriate (PERMISSION_DENIED or AUTHORIZATION_FAILED, for example). It should very rarely occur, so I don't think that the web-app needs to support it explicitly, but we should make sure we report it correctly in the webrtc client.

Comment 3 by zijiehe@chromium.org, Jul 28 2016 

In JingleMessage, we have a correctly error-code attached. If we do not plan to support this error message on UI, no further action is required for this bug.

Comment 4 by zijiehe@chromium.org, Sep 26 2016

Status: Fixed (was: Assigned)
No further action is required for this bug.

Comment 5 by ajnolley@chromium.org, Sep 27 2016

Status: WontFix (was: Fixed)
►

Sign in to add a comment