Comment 22 for bug 1504065

W dniu 06.12.2015 o 19:59, Matthew Paul Thomas pisze:
> "What's more, it's not the dialog, nor the shell, that decides to pause
> the video or not. It's the media player that does, because it's been
> unfocused. Do you believe that some dialogs should change focus, some
> shouldn't?"
>
> I'd happily answer in detail, but that issue seems to be four steps
> removed from fixing this bug. First, focus and layering are not the same
> thing. Focus stealing prevention is important, but on phones Unity might
> need to layer dialogs in front even when denying them focus, because --
> unlike on PCs -- it can't rely on the Launcher to show you that they've
> opened. All my examples assume the dialogs will be in front, but not
> necessarily focused.

What's the difference between a focused and an unfocused dialog, when
it's in front in both cases?

> Second, even if being unfocused was a reliable indicator of being in the
> background, that would be a highly questionable reason to pause video.
> For example, it would be annoying to pause music merely because the
> player is in the background -- but currently, 40% of music listening is
> done on YouTube, and is therefore video.

We don't support such a use case on the phone today, and while I'd argue
there's a need for an app that would do that for you (ignore the video
stream to save bandwidth and battery), I do get we need to think of such
a use case. Don't have a good answer how to behave here, though.

> Third, regardless of whether being in the background is a good reason to
> pause video, individual media-playing apps seem like the wrong place to
> make that decision. For example, a phone call should pause video, and
> pause music, and mute any other multimedia audio, in every app, when the
> call rings. Does that mean every media-playing app should contain code
> for pausing on phone calls? Of course not; app developers would usually
> not know, not remember, or not bother. It's a job for the media
> frameworks, not the apps.

Indeed, and that's how it works today, all multimedia streams are paused
when a stream plays in the "ringtone" role, such as an incoming call.
Whether the same should apply for incoming SMS is questionable, so it's
not as easy as "when there's a ringtone, pause", so we'll need more
smarts here still.

> And fourth, even if apps were responsible for pausing video, I don't
> think that pausing should have any effect on the volume warning dialog.
> I think that's the root problem, and the reason for my spec change
> above: as long as the dialog is up, audio pausing shouldn't change the
> active output role and therefore shouldn't dismiss the dialog.

Full agreement here.