Tested with Version 66.0.3343.3 (Official Build) dev (64-bit) and appears to be same issue. If you can check the  bug 758130 , it was logged in Aug and its been 6 months now and we are not able to use Google chrome for this iframe show/hide function for various issues.

Other browsers are always working as expected. And I personally believe this is the basic need/expectation from any browser.

All I am requesting is to expedite the outcome and give this high priority and fix it faster.

Thank you for your kind support.

Hi,

Can you please change this to priority 1 as this is a long going issue and this is supposed to work normal as all the other browsers do.

Thank you.

Sorry, I don't think this is P1.  Per  http://crbug.com/758130#c26 , it's not really a regression since this has never worked properly.  The symptom for the end user is not severe (scroll offset is reset, but rendering is otherwise correct and scrolling is not broken).  There is an easy workaround for the web developer (use visibility: hidden instead of display: none).  And the specs have nothing to say about this AFAIK.

It would be a nice "polish" fix but we have many more urgent issues.

While I appreciate your hard work, my point is, this is basic need. I can use IE, Edge, Firefox and make the iFrame display:none and display it back and it works like charm.

Using visibility: hidden does not help in different situations.

I don't know since when Google Chrome has this issue but all I know is it should work which is not working since at least Aug last year.

If its not P1 then its fine as long as its identified and fixed ASAP.

Thanks.

 Issue 826246  has been merged into this issue.

Yes this is a severe issue.  For instance when editing on Waze map editor, if I click a checkbox to add something in a feature I'm editing, it resets the scroll back to the top of the page.  I have to scroll all the way back through and find the info where I left off again.  Same thing happens when you go into settings and go to delete individual site settings/cookies.  If you scroll down and find one you want, you delete it and instead of preserving the scroll location it again resets back to the top of the page and you have to try to figure out where you left off again.  It is highly annoying and makes using many different systems useless here.  I've been using my PC instead lately, but since the chrome version there updated too now it's the same as my chromebook.  So awful.  

So is there going to be any solution available soon for this ?

I just checked the linked  Issue 826246  and there is not much update either. It is however marked Priority 1.

This is a severe issue for us as well. The switch "--disable-blink-features=DisplayNoneIFrameCreatesNoLayoutObject" fixes our problem, and https://bugs.chromium.org/p/chromium/issues/detail?id=819189 claims that fix was committed in Chrome 67, but it's not fixed in Chrome 68 for me.

Hi Guys,

I have just updated Google Chrome to Version 67.0.3396.62 (Official Build) (64-bit).

Tested the above issue and found the below outcome.

1 If the link in iFrame is external link : It works okay, it holds the previous scroll position.
2 If the link in iFrame is from same origin : it still resets the scroll position to 0.

Try the below examples for testing

1 - with external link

	https://codepen.io/pl47er/pen/mXJNJB

	1 - Open the link
	2 - Scroll the content down to ensure its not on top
	3 - Click "Hide / Show" button to hide the iframe
	4 - Click "Hide / Show" button to show the iframe

	Outcome - This will keep the scroll position.

2 - with same origin link

	https://codepen.io/pl47er/pen/zaqoLE

	1 - Open the link
	2 - Scroll the content down to ensure its not on top
	3 - Click "Hide / Show" button to hide the iframe
	4 - Click "Hide / Show" button to show the iframe

	Outcome - This will reset the scroll position to 0.

Thanks.

Hi Team,

Just checking if someone acknowledge the last message above ?

I can't believe that all the browsers are working normal apart from Chrome and it is going to be almost a year to fix this issue and still not 100%. I don't mean to be rude but its really long time to fix basic requirement, isn't it ?

Thanks for your hard work anyways.

I can't believe there is no response to this yet from Developers, even at least to acknowledge the information provided.

Thank you for the update in comment #9.  It is interesting to know that cross origin iframes do not exhibit this behavior.

I think it would be nice to fix this bug, but I don't have an ETA for you.  I wrote an assessment of its priority in comment #3, which I think is still correct.

Re the assessment in comment #3, you're incorrect, this did work in the past and is in fact a regression. We're telling clients not to use Chrome anymore, because of this bug. So, I mean, it's fine to say it's just an unimportant polish bug but in fact it is losing you users even now.

I am again disappointed by Google Chrome with version 69 [Version 69.0.3497.81 (Official Build) (64-bit)] that Google again failed to fix basic functionality in the browser. :(

The whole thing started breaking up since version Chrome version: 60.0.3112.90 mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=758130 and its been 9 releases and more than a year now.

I am also telling my users to use either Microsoft Edge or Firefox instead of Chrome, just loosing hope now.

@skobes : when this issue will be fixed? First raised on Aug 23 2017 and yes this is basic function of any browser which was working okay prior to version 60. You can actually try old version yourself. If you still think this is priority 2 and not 1, I think there is something wrong with the logic of deciding priority there (by Google).

@skobes @erikc...

May I please request some update on this ?