Block autoplay icon disappears when changing tabs from the arcticmonkeys website

RESOLVED FIXED in Firefox 66

Status

()

defect
P2
normal
RESOLVED FIXED
2 months ago
a month ago

People

(Reporter: dcicas, Assigned: alwu)

Tracking

(Blocks 1 bug, {regression})

66 Branch
Firefox 67
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox65 unaffected, firefox66+ fixed, firefox67 fixed)

Details

Attachments

(4 attachments)

Posted image doorhanger.gif

Affected versions

  • Fx Beta 66.0b6 BuildID: 20190207161357

Affected platforms

  • Win 10 x64
    Win 7 x32
    Ubuntu 18.04 LTS
    Ubuntu 16.04 LTS

Steps to reproduce
Preconditions:
media.autoplay.default = 1
media.autoplay.enabled.user-gestures-needed = true

  1. Open a new window.
  2. Reach https://www.arcticmonkeys.com/
  3. Check the Site Information panel.
  4. Travel to another open tab.
  5. Go back to the arctic monkeys tab.

Expected result

  • The block autoplay doorhanger is still displayed.

Actual result

  • The block autoplay doorhanger is not displayed and in the Site Information panel, there is no Block/Allow option.

Regression range
Has no regression range.

Additional notes
The Block/Allow options are not displayed when first reaching the Arctic Monkeys website.

Since we no longer use the door hanger I believe this no longer relevant.

Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
(Assignee)

Comment 2

2 months ago

That's not about the doorhanger, it's related with control center and icon. I can reproduce it on Beta, but it works fine on Nightly. Ni Dale to see if he know what happens here.

Status: RESOLVED → REOPENED
Flags: needinfo?(dharvey)
Resolution: WONTFIX → ---
Summary: Block autoplay doorhanger disappears when changing tabs from the arcticmonkeys website → Block autoplay icon disappears when changing tabs from the arcticmonkeys website

So you're saying 67 is unaffected?

Component: General → Site Identity and Permission Panels

Comment 4

2 months ago

I can reproduce the issue on Nightly67 Win10.

Steps

  1. Open https://www.arcticmonkeys.com/ [Tab 1]
  2. Check the Site Information panel.
  3. Open new tab [Tab 2]
  4. Go back to the arctic monkeys tab[Tab 1].
    --- observe the autoplay block icon
    (optionaly, if not reproduced)
  5. Reload(F5) the arctic monkeys tab[Tab 1].
  6. Switch to the other tab[Tab 2]
  7. Go back to the arctic monkeys tab[Tab 1].
    --- observe the autoplay block icon

Axtual Results:
The block autoplay icon disappears in the left side of urlbar

Expected Results:
The block autoplay icon should be displayed in the left side of urlbar

Regression Window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=73f92838946aac0aab5760bada1a1e8e2218a3e1&tochange=3f5a132b7e4f7579209ca906f9ec79059e426f26

Blocks: 1512283
Status: REOPENED → NEW

Comment 5

2 months ago

:alwu

Your patch seems to cause the regression.
Can you please look into this?

Flags: needinfo?(dharvey) → needinfo?(alwu)
(Assignee)

Comment 6

2 months ago

Transfer NI to Dale, who is working on front-end side for blocking autoplay.

Flags: needinfo?(alwu) → needinfo?(dharvey)

Dale, any chance of this making 66?

When is the deadline? asked a few times, I am slammed right now but I should be able to take a look over the weekend hopefully and best case have something for monday

Flags: needinfo?(dharvey)
Priority: -- → P2
Assignee: nobody → dharvey
Status: NEW → ASSIGNED

ok so got some time to investigate and turns out this could be quite a big issue, basically we have a few different bugs which cause the icon to be shown / hidden when its not supposed to, I have patches that fix them in https://bugzilla.mozilla.org/show_bug.cgi?id=1522053 + https://bugzilla.mozilla.org/show_bug.cgi?id=1522058. However some of these bugs are hiding other bugs including on here.

When the frontend sees a 'globalyblocked' event, it sets some state which shows the blocked icon then adds a listener which removes that state as soon as we navigate, we only show the blocked icon when a request has been made that has been blocked

However when a page is loaded from the bf cache by visiting a page, navigating elsewhere then pressing back. While you would expect an icon to show (and it currently does due to bugs). The media is never actually triggered to play (due to bfcache magic that I dont quite understand) and so never sends the event and when those bugs are fixed, the icon wont show

I am not sure that the frontend has enough information to be able to handle this case, asking Alastor for suggestions

(Assignee)

Comment 10

2 months ago

Hi, Dale,

This patch will dispatch globallyAutoplayBlocked event again when the document, which hasn't be allowed to autoplay and has been blocked before, is back from BFCache.

Could you try this patch to see if it's what you need?

Thank you.

Flags: needinfo?(dharvey)

With the above 2 patches landed that fixes the issue for me, I dont think there is a way for the frontend to handle this itself so I think this is the right fix, will reassign, many thanks

Assignee: dharvey → alwu
Flags: needinfo?(dharvey)
(Assignee)

Comment 12

2 months ago

In order to display blocking icon when the document comes back from the bfcache, we have to notify front end what's the current blocking status.

As the front end side would clear blocking autoplay information when nagivation occurs, and the media might not invoke the play again when they comes back from the bfcache.

Therefore, we should notify front end side that the site is still being blocked, and we should show blocking icon for it.

Is this ready to land? Waiting on review?

Do you think this issue should block the rollout on 66? (We can still uplift, but I'd like to fast track this including verification and possibly some exploratory testing, if so)

Flags: needinfo?(dharvey)
Flags: needinfo?(alwu)
(Assignee)

Comment 15

2 months ago

Now I'm doing the final testing to ensure the test can run well on all platforms, I will land my patch today.

I think this issue is not a blocker for our plan, but it would be good if we can uplift the patches to beta66.

Flags: needinfo?(alwu)

I have requested uplift on https://bugzilla.mozilla.org/show_bug.cgi?id=1522053 + https://bugzilla.mozilla.org/show_bug.cgi?id=1522058 as well

They are all seperate bugs but with the same outcome that the icon is showing when its not supposed to, would be good to have them all landed together for any exploratory testing

Flags: needinfo?(dharvey)

Comment 17

2 months ago
Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6e3eb5df50ff
part1 : notify the front end side to show the blocking icon if the site is still being blocked after it's back from the bfcache. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/9adad198b9b4
part2 : modify test to ensure we would get blocked event again when navigating from the bfcache. r=daleharvey
(Assignee)

Comment 18

2 months ago

setting NI as a uplift reminder.

Flags: needinfo?(alwu)

Comment 19

2 months ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
(Assignee)

Comment 20

2 months ago

Comment on attachment 9047487 [details]
Bug 1526355 - part1 : notify the front end side to show the blocking icon if the site is still being blocked after it's back from the bfcache.

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: None
  • User impact if declined: Blocked icon won't show again when user navigate the site back from the bfcache.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: see comment0
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): What this patch did is to dispatch an extra event to notify front end side to show the blocked icon, we didn't introduce any other behavior changes. In addition, we also have an automation test for this issue.
  • String changes made/needed: none
Flags: needinfo?(alwu)
Attachment #9047487 - Flags: approval-mozilla-beta?
Flags: qe-verify+

I've tested on latest Nightly 67.0a1 (2019-03-05) and I can still reproduce the issue (using the same steps from Description): the blocked icon isn't show again when user navigate the site back.

Any thoughts here?

Flags: needinfo?(alwu)
(Assignee)

Comment 22

a month ago

I've confirmed that my patches works as expected, the blocked event will be dispatched again when the page which has been blocked before comes back from the bfcache.

According comment11, this issue should be fixed with other two patches in bug1522053 and bug1522058, so NI Dale to confirm this issue.

Flags: needinfo?(alwu) → needinfo?(dharvey)

Hmm, those two patches landed in nightly before Camelia tested, though.

When I tried this in Nightly just now, it seems to work as expected. I still see the block autoplay icon in the address bar and in the site info panel.

Comment on attachment 9047487 [details]
Bug 1526355 - part1 : notify the front end side to show the blocking icon if the site is still being blocked after it's back from the bfcache.

Let's uplift this and re-verify in beta 14.

Attachment #9047487 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Yup, have tested every combination that I could get to reliably fail before and are all working

If you retest and see something again lets open a new bug and cc / needinfo me on it, thank

Flags: needinfo?(dharvey)

We still reproduce this issue on Firefox 67.0a1 and Firefox 66 Beta 14 and based on discussions from #block_autoplay slack channel, we logged a new bug - bug 1534219.

You need to log in before you can comment on or make changes to this bug.