This sounds like Bug 1294823? I don't know. STR: 1) In latest Nightly, go to http://m.sfgate.com/news/article/sf-homeless-poop-reddit-soma-human-waste-9968963.php 2) Let the page load Expected: The video plays in its frame, and I can scroll and like, read about this amazing story. Actual: The video autoplays and blocks interaction with the page (is this fullscreen?). No controls and I have to hit back to close it. (originally reported by blassey on webcompat.com)

Similar to bug 1301050?

Brad wants to just add an 'X' button somewhere. I think that's fine.

Sebastian, it may be easiest to have a front-end person look at this.

Okay, I'll re-flag this for triage and I'll talk to the Taipei team.

Is it possible to prevent it from going fullscreen?

I don't find a proper drawable for the button, just pick random one for evaluation. Adding a button and stop player in its click-listener. Is this expected implementation?

Yeah, I think that's what we need here. But let's confirm with antlam.

And I think I need a drawable for that button, it is like the Fullscreen button[1]. [1] (it is white...) https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/drawable-xxhdpi/fullscreen.png

Can Jack also to give some advice? Thanks

Hey Jack, So per the discussion in the latest sprint planning, we consider it as P1 because it potentially breaks user experience. This bug has both UX and visual design dependencies. Please look into this and let target to have design ready before next sprint planning happens (Jan23).

Some updates from the media folks: https://bugzilla.mozilla.org/show_bug.cgi?id=577084#c54 If the video playback window is embedded then this bug would be INVALID. Let's wait a bit for the conclusion from bug 577084

Leaving the NI here for Jack :)

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #12) > Some updates from the media folks: > https://bugzilla.mozilla.org/show_bug.cgi?id=577084#c54 > If the video playback window is embedded then this bug would be INVALID. > Let's wait a bit for the conclusion from bug 577084 As far as I can see for now, bug 577084 should not be able to happen soon, at least not in Q1. So if this bug can be fixed earlier, maybe we don't need to wait bug 577084.

(In reply to Blake Wu [:bwu][:blakewu] from comment #14) > As far as I can see for now, bug 577084 should not be able to happen soon, > at least not in Q1. So if this bug can be fixed earlier, maybe we don't need > to wait bug 577084. In such case, Jack could you come out with a interim solution given bug 577084 may come later?

I don't think at this moment we have clear schedule to fix it.

Mass wontfix for bugs affecting firefox 52.

Mass change P1->P2 to align with new Mozilla triage process.

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.