What steps will reproduce the problem:
@jericbryledy cause layout is generated by javascript, I don't like it too
@kybarg The reason is not really the JavaScript but the fact that we enclosing the content into a scrolling <div>.
@jericbryledy I don鈥檛 think we can do anything about this. It鈥檚 the browsers job really to remember scroll positions while reloading (which Chrome does just fine). You鈥檇 have to file an upstream bug against your respective browser.
Oh I see. Just FYI, I have tried http://www.getmdl.io/ on Chrome and Firefox for both Windows and Linux, + Internet Explorer which none remembers the scroll.
@surma Testing here on the latest dev channel of Chrome it isn't going back to the previous scroll position either. Looks like this is a side-effect of how layout is handled.
Removing position:absolute from .mdl-layout__container seems to fix this.
https://github.com/google/material-design-lite/blob/master/src/layout/_layout.scss#L58
will this give side effects though?
I think it does. The line was added to fix a layout issue but the commit does not reference a GitHub issuse.
Commit: https://github.com/google/material-design-lite/commit/d8e63d676b3a11d01e3e1c960d3d88d8fa5f1116
how do you reopen an issue?
You can't re-open your own issue on github if a collaborator has closed it. You'd need to file a new one, perhaps, referencing the old one and giving some reasons why it shouldn't just get closed again as being a duplicate. Good luck.
Please do _not_ file new issues simply because you feel one was closed improperly. We read follow-up comments and will reopen if appropriate.
Nothing can be done here without a layout refactor in a major version since any change could break things already relied upon.
@Garbee @addyosmani I was thinking about reopening this and marking it as v2 or something. A refactor of the entire layout component _might_ be desirable and feasible. WDYT?
I think we have enough little problems with Layout cropping up. Instead of re-opening we should make a new issue to track the layout issues brought up that need a BC break. Tag it right and use it for tracking reference.
SGTM
In my view this a very serious problem and so user-unfriendly that I cannot use the framework for any real stuff.
We know it is a real problem. However, we are doing our best to _not_ break things within a major version. So there is nothing we can do here until 2.x when a full layout refactor is being carried out.
Fair enough. As a workaround the scroll position can be stored when a page is unloaded and restored when the page is loaded again (see https://developer.mozilla.org/en-US/docs/Web/API/History_API) A lot of the stuff I work with uses history.state anyway...
It would be very informative if the examples/templates included examples of "single page" applications. The examples would illustrate the best/correct way to structure multiple pages in the DOM, how to transition between pages and how to "remember" the scroll position on the different pages.
For those who lost faith)
Now scroll position is remembered!
var mainScrollArea = document.getElementsByClassName('mdl-layout__content')[0];
var scrollTimeout;
window.onload = function () {
if(window.location.href == localStorage.getItem('lastUrl')) {
mainScrollArea.scrollTop = localStorage.getItem('scrollTop');
} else {
localStorage.setItem('lastUrl', window.location.href);
localStorage.setItem('scrollTop', 0);
}
}
mainScrollArea.addEventListener('scroll', function() {
clearTimeout(scrollTimeout);
scrollTimeout = setTimeout(function() {
localStorage.setItem('scrollTop', mainScrollArea.scrollTop);
}, 100)
});
This worked for me :
Add this code in css file AFTER importing material.min.css
.mdl-layout__container {
position: relative;
}
@pratik the header wouldn't follow you as you scroll down the page if you do that
Most helpful comment
For those who lost faith)
Now scroll position is remembered!