1. Stop is only present for Presentation API/Video Fling, right? IIRC, MediaStyleCompat creates a small x in the notification on old platforms where dismissing by swipe is not possible. We don't need a button space for that.
2. Yes, we prefer paired actions to non-paired once. The question is if we have three actions to show and all actions supported, do we prefer tracks over seeking (I tend to thinks tracks are more important for music while seeking might be better for something like podcasts -- so I would go with tracks).

1. I mean: do we want actions other than STOP to be used in Presentation API/Video Fling?
2. I tried with Android wear, it's interesting that they never show seek forward/backward:
  * If seek forward/backward is supported but previous/next track is not, it only shows increase/decrease volume.
  * If seek forward/backward is supported and only one of previous/next track is supported, it only shows the supported previous/next track button.

I tend to prefer keeping the behavior consistent with Android wear. Also, there are some cases where one of previous/next track is temporarily unavailable, such as playing the first/last track in a playlist (native apps usually show a grey button for it, maybe we can also have grey buttons to indicate it's disabled).

Anyway, we need UX feedback on the decision :)

1. I believe we haven't figured out how MediaSession interacts with RemotePlayback API/VideoFling, not to say about Presentation API.

It's pretty likely for the default MediaSession to be used with both though and if it's set on a media element that's being remoted, I don't see why it shouldn't work.

There seems to be no command for next/prev track for MediaRouter APIs (what we use for RemotePlayback/VideoFling now; see https://developer.android.com/reference/android/support/v7/media/RemotePlaybackClient.html), while for the Cast SDK used for Presentation API there are (see https://developers.google.com/android/reference/com/google/android/gms/cast/RemoteMediaPlayer.html#queueNext(com.google.android.gms.common.api.GoogleApiClient, org.json.JSONObject)).

We could still try to do default handing for RemotePlayback like seek to 0, seek to duration.

2. Could you clarify what being consistent with Wear means to you? Given they don't show half of the buttons we're going to support, it's unclear to me.

Not sure how we'd specify a disabled next/prev track via the API:
- the page doesn't have a handler for the action but declares it supported
- the opposite?
- there's a third-state like when the page has the action listed as supported but can mark it as disabled
- we provide a queuing API for the UA to know about the items the page wants to play

When do you plan to reach out for the UX feedback?

1. Yeah, I think we could use the same code for next/previous track and seeking if we need them for RemotePlayback API/VideoFling

2. > Could you clarify what being consistent with Wear means to you? Given they don't show half of the buttons we're going to support, it's unclear to me.

Yes, maybe we shouldn't be consistent with Wear, since it's their limitation, not ours.
I found out different apps show different icons, esp. next/prev track is more important for music apps, while seek forward/backward is more important for podcast/audiobooks. We probably still need an attribute in the MediaSession API to indicate the action priorities.

> When do you plan to reach out for the UX feedback?
Don't have plan yet. Maybe after Mounir's back from vacation?

Isn't this fixed? :) Marking for M59 otherwise.

Yes. The rest of the issue should be tracked on the spec instead of here. See https://github.com/WICG/mediasession/issues/151