Bisected to r495331 = 5d8010e1fc081481d0646618e700b51a4699ab4c
"Reenable feature policy control over fullscreen"

Quoting the CL:

   Dynamic modification of the allowfullscreen flag has no effect until
   the iframe contents are navigated/reloaded.

So this is working as intended.

This functionality is different from IE and Firefox. Is there a workaround here?

You need to set the attribute before the iframe starts loading, otherwise you'll have to reload the iframe contents.
Chrome implements this spec: https://wicg.github.io/feature-policy/#integration-with-html

  The allowfullscreen attribute is a boolean attribute. 
  When specified, it indicates that Document objects in the iframe element’s 
  browsing context should be initialized with a feature policy which allows 
  the fullscreen feature to be used from any origin

It's not clear to me whether the spec explicitly disallows dynamic changing of this attribute. And if it does, why. From a layman's point of view, I'd say the embedder page has every right to change this attribute dynamically on an already loaded iframe. It'd be helpful if iclelland@ could clarify this.

+iclelland@ to clarify, but I also think that this was an intentional change and you're seeing expected behavior.  It also matches how the "sandbox" attribute and "allow" feature policy attribute work.  For the allowfullscreen to take effect, you need to navigate the iframe (e.g., set the src to something else) after changing allowfullscreen.

Yes, this is an intentional change to the platform to align with "sandbox" and "allow", and the existing "allowusermedia" and "allowpaymentrequest" attributes. The embedder certainly can change the attribute, but like sandbox, the result doesn't take effect until the frame navigates.

As part of feature policy, one of the goals is for sites to have a consistent set of available features, which doesn't change over the lifetime of the document.

The original intent thread on blink-dev for this is here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/UKChYGBYvSk/dXXdHGyhBwAJ

iclelland@ Thanks for the update.

As per comment #5, as this is an intentional change, can we close this issue?

Thanks.. 

As per comment #7 adding Needs-Feedback to it.

Thanks.!

Ian, I think we can close this as WAI. Please comment/confirm.

Yes, this is WAI. The HTML spec is being updated with this behaviour, and I'm going to be filing browser bugs at that point for the other engines.

The workaround is generally going to be to grant fullscreen access to the page before loading it, or to reload the frame after adding the attribute. (If you control the destination page, you can even have it stash any local state and reload itself once the container attribute has been updated)

WontFixing per #10.