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.

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.

So you're saying 67 is unaffected?

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

:alwu

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

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

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

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

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.

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

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)

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.

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

setting NI as a uplift reminder.

https://hg.mozilla.org/mozilla-central/rev/6e3eb5df50ff
https://hg.mozilla.org/mozilla-central/rev/9adad198b9b4

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

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?

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.

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.

https://hg.mozilla.org/releases/mozilla-beta/rev/cd093abd9a5c
https://hg.mozilla.org/releases/mozilla-beta/rev/30da98d1f31c

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

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.