In addition to scolling attr, name, marginwidth and marginheight may also need to fix;
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLFrameElementBase.cpp?sq=package:chromium&rcl=1472599251&l=136

@003mjf: Could you please have a look at the attached video and let us know if this is the correct behavior to repro this issue.

Else, provide us the screen-recording for better understanding.

Thank you.

Deleted: 642603.mov 21.8 MB

642603.mov 21.8 MB Download

@rnimmagadda: Thank you for your reply.
Instead of directly modifying the code, please click the input button in the demo.

Deleted: demo.webm 1.5 MB

	demo.webm 1.5 MB View Download

Add Firefox screen-recording:

Deleted: demo_firefox.webm 2.2 MB

	demo_firefox.webm 2.2 MB View Download

It's almost a week since screen-recordings were attached. Could someone please look into this issue?
I think this bug can be categorized into component:Blink>HTML>IFrame.

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 53.0.2785.143

This is a Non-Regression issue existing from M30 - # 30.0.1549.0

Deleted: 642603.mov 2.9 MB

642603.mov 2.9 MB Download

I can repro the issue. When scrolling is set to "no", I can still scroll. *But* if the page is resized, then I can't scroll the iframe anymore. I've tracked this down to the fact that we read the frame owner's scrollingMode attribute in layout(). I bet we have the same issue with the other attributes (as mentioned as a possibility in #1. Should be easy enough to call setNeedsLayout on the contentFrame() and I've confirmed this works so I'll submit a fix when I get some time.

This gets a little more tricky for remote frames. FrameTreeNode::frame_owner_properties_ has a comment explicitly stating that the set properties won't take effect until the frame is next navigated. We could probably prod the remote frame to set layout and have it work as well. dcheng@/lazyboy@, does that sound about right or was this an explicit choice?

The original intention when we implemented the remote frame code was to match the behavior of local frames and only have attribute changes be reflected on a new load in the frame.

That being said, that's obviously kind of broken today since we can re-read this value during layout (we didn't check the resize case =)

Sadly, this is something that was only specced in HTML4 and is underspecified. How do other UAs behave? In particular, Edge and IE?

I tried Edge and Safari, both have the expected behavior that the attribute change takes effect immediately, without need for a navigation or resize.

Should we clarify this behavior in the spec somewhere? This is also coming up for things like feature policy in https://codereview.chromium.org/2254533002/

Not sure what we should be doing in remote frames but it seems pretty clear and straightforward to fix this for local frames. Chao, could you please take a look. The code that sets the scrolling mode is in FrameView::calculateScrollbarModes which gets called from layout. We should force recalculation of this (and other iframe attributes) when they're set (or schedule a layout).

We should fix this for remote frames as well, since this is the behavior that other browsers expose.

HTMLFrameElementBase::frameOwnerPropertiesChanged is method get called when the attr update. 

For LocalFrame:

This issue can be fix via adding FrameView::setNeedsLayout() to mark the frame need relayout in/after HTMLFrameElementBase::frameOwnerPropertiesChanged.

For RemoteFrame:

I don't see any method to mark frame need relayout in RemoteFrame. dcheng@ can you please give me some advice?

#16: for RemoteFrames, seems like you might be able to call setNeedsLayout in WebFrame::setFrameOwnerProperties if the scrolling mode changed (and the WebFrame is local).  When frameOwnerPropertiesChanged is called for a remote frame, the updated properties are plumbed through the browser process and to this function in the renderer process that has the corresponding local frame.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2e671cf88d579e7a2392dff0383f47dae2655ab5

commit 2e671cf88d579e7a2392dff0383f47dae2655ab5
Author: chaopeng <chaopeng@chromium.org>
Date: Wed Nov 23 00:55:32 2016

Support script modify iframe scrolling, marginWidth and marginHeight attr

For scrolling:
call FrameView::setNeddLayout in LocalFrame to update the behaviour.

For marginWidth and marginHeight:
call setIntegralAttribute to set the attr

This patch works for LocalFrame and RemoteFrame,

BUG= 642603 

Review-Url: https://codereview.chromium.org/2507023002
Cr-Commit-Position: refs/heads/master@{#434047}

[add] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/LayoutTests/http/tests/misc/iframe-script-modify-attr-expected.html
[add] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/LayoutTests/http/tests/misc/iframe-script-modify-attr.html
[add] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/LayoutTests/http/tests/misc/resources/iframe-big.html
[modify] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/Source/core/dom/Document.h
[modify] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/Source/core/html/HTMLFrameElementBase.cpp
[modify] https://crrev.com/2e671cf88d579e7a2392dff0383f47dae2655ab5/third_party/WebKit/Source/web/WebFrame.cpp