Support user override of mirroring |
|||||||
Issue descriptionCurrently we don't support users overriding the default Cast action from a site by explicitly mirroring (e.g., desktop). This is a regression over the legacy extension behavior - see b/27547457. We should support a user_override option so that users can explicitly mirror tab/desktop instead of casting.
,
Mar 10 2016
This seems like a feature request for the Cast SDK. Please file a bug against the Cast MRP for followup.
,
Mar 10 2016
But doesn't the MRP need to know whether the user has overridden the default behavior from MR? That data would seem to live there.
,
Mar 16 2016
I guess I don't follow what you mean by "override." The user can select tab or desktop cast mode using the picker, and the MRP will get a route request with that media source. If you want a way for this preference to persist - that is something that the Cast MRP could possibly keep track of.
,
Mar 16 2016
Vadim, is this all in the Cast MRP, or do you need data from MR?
,
Mar 16 2016
I believe it's all in MR UI and should not touch Cast MRP.
,
Mar 23 2016
Please write up a short PRD describing this feature, as I'm still not sure what is being asked for. Also removing R-V-G as I don't see anything sensitive.
,
Mar 28 2016
Mark, the basic requirement here is that if the user has explicitly started Desktop mirroring prior to going to a Cast-enabled site, that the site needs a way of detecting that and not auto-transitioning to flinging. AIUI there's no way for the Cast MRP to query MR to find out if the user is currently desktop mirroring, in order to avoid the default auto-transition behavior. How could the MRP get this information?
,
Mar 28 2016
I don't think the MR needs to be involved, since the only time this happens is when the Cast MRP decides to switch a Cast device from a desktop mirroring route to a flinging route. We'll discuss amongst ourselves.
,
Mar 30 2016
After discussion this situation can be resolved within the MR component extension. Will track fix there. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by sko...@chromium.org
, Mar 10 2016