The current behavior will be evaluated with the latest Nightly v100.0a1 on Windows 10, Ubuntu 20.04 LTS and Mac OS 11.6.4 based on these 4 steps: 1. Launching the PiP. 2. Scrolling the original video player out of the viewport. 3. PiP Video and controls functionality. 4. Continue scrolling the website's timeline. A. Twitter: all OSes 1.1 When the user scrolls Twitter and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched and playing. 1.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 1.3 The user can now replay the video and control the sound from the PiP. 1.4 However, when he scrolls further, the PiP will close automatically. ** The issues I see here (Twitter + any OS) are: ** ** PiP pauses when scrolling down. (steps 2) ** -> will be addressed in this bug, if ever. ** PiP closes by itself when scrolling further. (step4) ** -> should I log a different bug for this? B. Facebook: Unfortunately, it appears that Facebook behaves differently on Windows than it does on Mac OS and Ubuntu 20. * Win 10: 2.1 When the user scrolls Facebook and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched but NOT playing as the PiP click also counted as video pause. 2.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 2.3 If he then clicks the Play button in the PiP, the video stutters, but does not play. If the user then clicks the "Resume video" in the main video/player, the video will play in PiP. If he clicks the Mute button in PiP, the video will also pause. 2.4 When he scrolls further, the PiP will remain on screen in a paused state (not close). ** The issues I see here (Facebook + Win 10) are: ** ** The clicking of the PiP toggle counts as a video click that will pause the video in the opened PiP or open the video's own page (step 1). ** -> should I log this separately? ** The fact that Facebook's own PiP does not take over, as it does with Mac OS and Ubuntu! (step 2) ** -> should I log this separately? ** The incorrect behavior of the PiP controls (step 3) ** -> this is addressed in this bug, if ever. ** The fact that the PiP does NOT close, considering that it can't be made to play while scrolling (step 4) ** -> should I log this separately? * Mac OS 11 and Ubuntu 20: 2.1 When the user scrolls Facebook and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched and PLAYING (in contrary to behavior on Windows where the click counts as video pause). 2.2 If he scrolls down enough for the original video/player to move out of the viewport, the PiP will close as Facebook's own PiP will take over and play the video further (as opposed to the behavior on Windows where Facebook does not open its own PiP). 2.3 The user can now scroll further using Facebook's own PiP OR open a new PiP from it. With both of these PiPs, the user will be able to control play/pause and mute/unmute while scrolling Facebook. 2.4 When he scrolls further, the PiP will remain on screen and properly working. ** I would say this is acceptable. ** -> don't you? C. Reddit: Unfortunately, it appears that Reddit also behaves differently on Windows than it does on Mac OS and Ubuntu 20. * Win 10: 3.1 When the user scrolls Reddit and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched but NOT playing as the PiP click also counted as video pause OR SOMETIMES the PiP click will also count as a video click, which will redirect to the video's page. 3.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 3.3 The user can now replay the video and control the sound from the PiP. 2.4 When he scrolls further, the PiP will remain on-screen (not close). ** The issues I see here (Reddit + Win 10) are: ** ** The clicking of the PiP toggle counts as a video click that will pause the video in the opened PiP or open the video's own page. (step 1) ** -> should I log this separately? ** PiP pauses when scrolling down. (steps 2) ** -> this will be addressed in this bug, if ever. right? * Mac OS 11 and Ubuntu 20: 3.1 When the user scrolls Reddit and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched but and playing (as opposed to the behavior seen on Window where the PiP launches paused or even counts as video click). 3.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 3.3 The user can now replay the video and control the sound from the PiP. 3.4 When he scrolls further, the PiP video will pause again, but will remain on-screen (not close) and can be re-player (again). ** The issues I see here (Reddit + MacOS/Ubuntu) are: ** ** The PiP video pauses (twice) when scrolling down. (steps 2 and 4) ** -> this will be addressed in this bug, if ever. right? These scenarios will be included in the PiP test cases and the test runs for Beta 100 and later. @ania: I will start by apologizing for the "wall of text", but I don't see any other way to address these issues in detail. Can you give me some feedback on my opinions relating to the different behaviors I consider valid/invalid? (the ** starred paragraphs **)
Bug 1547349 Comment 27 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The current behavior will be evaluated with the latest Nightly v100.0a1 on Windows 10, Ubuntu 20.04 LTS and Mac OS 11.6.4 based on these 4 steps: 1. Launching the PiP. 2. Scrolling the original video player out of the viewport. 3. PiP Video and controls functionality. 4. Continue scrolling the website's timeline. A. Twitter: all OSes 1.1 When the user scrolls Twitter and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched and playing. 1.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 1.3 The user can now replay the video and control the sound from the PiP. 1.4 However, when he scrolls further, the PiP will close automatically. ** The issues I see here (Twitter + any OS) are: ** ** PiP pauses when scrolling down. (steps 2) ** -> will be addressed in this bug, if ever. ** PiP closes by itself when scrolling further. (step4) ** -> should I log a different bug for this? B. Facebook: Unfortunately, it appears that Facebook behaves differently on Windows than it does on Mac OS and Ubuntu 20. * Win 10: 2.1 When the user scrolls Facebook and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched but NOT playing as the PiP click also counted as video pause. 2.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 2.3 If he then clicks the Play button in the PiP, the video stutters, but does not play. If the user then clicks the "Resume video" in the main video/player, the video will play in PiP. If he clicks the Mute button in PiP, the video will also pause. 2.4 When he scrolls further, the PiP will remain on screen in a paused state (not close). ** The issues I see here (Facebook + Win 10) are: ** ** The clicking of the PiP toggle counts as a video click that will pause the video in the opened PiP or open the video's own page (step 1). ** -> should I log this separately? ** The fact that Facebook's own PiP does not take over, as it does with Mac OS and Ubuntu! (step 2) ** -> should I log this separately? ** The incorrect behavior of the PiP controls (step 3) ** -> this is addressed in this bug, if ever. ** The fact that the PiP does NOT close, considering that it can't be made to play while scrolling (step 4) ** -> should I log this separately? * Mac OS 11 and Ubuntu 20: 2.1 When the user scrolls Facebook and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched and PLAYING (in contrary to behavior on Windows where the click counts as video pause). 2.2 If he scrolls down enough for the original video/player to move out of the viewport, the PiP will close as Facebook's own PiP will take over and play the video further (as opposed to the behavior on Windows where Facebook does not open its own PiP). 2.3 The user can now scroll further using Facebook's own PiP OR open a new PiP from it. With both of these PiPs, the user will be able to control play/pause and mute/unmute while scrolling Facebook. 2.4 When he scrolls further, the PiP will remain on screen and properly working. ** I would say this is acceptable. ** -> don't you? C. Reddit: Unfortunately, it appears that Reddit also behaves differently on Windows than it does on Mac OS and Ubuntu 20. * Win 10: 3.1 When the user scrolls Reddit and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched but NOT playing as the PiP click also counted as video pause OR SOMETIMES the PiP click will also count as a video click, which will redirect to the video's page. 3.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 3.3 The user can now replay the video and control the sound from the PiP. 2.4 When he scrolls further, the PiP will remain on-screen (not close). ** The issues I see here (Reddit + Win 10) are: ** ** The clicking of the PiP toggle counts as a video click that will pause the video in the opened PiP or open the video's own page. (step 1) ** -> should I log this separately? ** PiP pauses when scrolling down. (steps 2) ** -> this will be addressed in this bug, if ever. right? * Mac OS 11 and Ubuntu 20: 3.1 When the user scrolls Reddit and (finally) finds a long enough video to activate PiP and clicks the toggle, the PiP is launched but and playing (as opposed to the behavior seen on Window where the PiP launches paused or even counts as video click). 3.2 If he scrolls down enough for the original video/player to move out of the viewport, the video in the PiP pauses. 3.3 The user can now replay the video and control the sound from the PiP. 3.4 When he scrolls further, the PiP video will pause again, but will remain on-screen (not close) and can be re-player (again). ** The issues I see here (Reddit + MacOS/Ubuntu) are: ** ** The PiP video pauses (twice) when scrolling down. (steps 2 and 4) ** -> this will be addressed in this bug, if ever. right? These scenarios will be included in the PiP test cases and the test runs for Beta 100 and later. @ania: I will start by apologizing for the "wall of text", but I don't see any other way to address these issues in detail. Can you give me some feedback on my opinions relating to the different behaviors I consider valid/invalid? (the ** starred paragraphs **)