The relevant bit from the regulation, as quoted in the spec, is "Provide a means to actively inform the user of the increased sound pressure ... Any means used shall be acknowledged by the user". Tapping a button in a dialog is acknowledgement by the user. Toggling a settings switch, ahead of time, would arguably be acknowledgement by the user (I'd want to check with a lawyer first). But maybe or maybe not noticing that the volume gauge is a different color is not acknowledgement by the user.
"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. 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. 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. 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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mediaplayer-app in Ubuntu. https://bugs.launchpad.net/bugs/1504065 Title: Cannot play videos when a wired headphone is connected Status in Canonical System Image: Confirmed Status in The Sound Menu: New Status in mediaplayer-app package in Ubuntu: Confirmed Status in unity8 package in Ubuntu: Confirmed Bug description: When having a wired headset connected to the device, video playback keeps on being paused as soon as playback is started. Looks like some snap-decision notification is shown, but it's too short time to read what it actually says because it disappears again when the playback stops again. <https://wiki.ubuntu.com/Sound#limits>: "So that both buttons do what you expect and the dialog does not disappear unexpectedly, any role change should be postponed as long as the dialog is up." To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1504065/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
