Attempt to swipe down very slowly instead so as to scroll rather than refresh. Instead of scrolling, the page will refresh. Then swipe down to scroll back up to the top of the page. The address bar will remain and the footer will not be shown. In a single swipe up, scroll down, allowing inertia to take the scrolling to almost the bottom of the page. (Similar thing happens with address bar at top.) The address bar will be displayed. On Firefox Nightly 97.0a1 but not on Firefox Daylight 95.2.0, the interaction between page refresh and scrolling is broken as follows: With the address bar at the bottom, visit the example above.This is already covered by Firefox core bug 1673517. White space is displayed below the footer.Compared to the other browsers I checked (which didn't include iOS I'm afraid), Firefox for Android is still buggy for this case the following respects: ![]() I've taken another look at the example I presented in #13797 (comment) in Nov 2020, which can be seen (with minor variations) here. I went back and reviewed my contributions to this thread. This covers cases like the ublock settings page (where an iframe's viewport takes up the page viewport the iframe would remain scrollable with the smaller viewport, as desired), as well as cases like a mapping or drawing application where the canvas size would simply be reduced by the height of the toolbar. If the page has content height = viewport height, then the content height would shrink.a GitHub issues list with a fixed number of issues to display) that just happens to fall into this small range, then the page would become a bit scrollable, like you said. If the page has a fixed content height (e.g.The resulting behaviour would depend on the page: My suggestion for how to handle this case, as mentioned, is to size the viewport to the (window - toolbar) height. Yep, I believe this covers almost all of the problematic scenarios remaining now that bug 1633322 is fixed, and it would be good to have a GV ticket on file for this. pages have a height bigger than (window - toolbar) but smaller than window (ending underneath the toolbar), like I think is the case here - Can't scroll when the page is taking almost the entire screen #10477.It's worth filing a GV bug about this, though I don't have a great solution in mind for it :/ (But again, it may be rare enough that it doesn't matter.) I think such pages are (very) rare and I would consider them badly designed, but for these we would run into the "content obscured by toolbar" problem. via window.scrollTo() in response to these events). It's possible that a page has scrollable content (content size exceeds viewport size), and preventDefault()s these events, and performs scrolling manually (e.g. In these cases, there should be no problem related to the toolbar (as of bug 1633322). For example, a mapping application will typically react to such an event by drawing new content onto a fixed-size map canvas. In most cases, when a web app has a listener which preventDefault()s these events, the page does not actually have scrollable content (that is, the page's content size does not exceed the viewport size). They cannot be preventDefault()ed (the scrolling has already happened) and are not interesting for this discussion.) (There are also scroll events, which are more like a notification to web content that scrolling has been performed. They are interesting because they can be preventDefault()ed by web content in which case the browser does not scroll. These are generally wheel, touch, and pointer events. This is only a problem if we're in the third case "pages have a height bigger than (window - toolbar) but smaller than window (ending underneath the toolbar)", and the solutions for that will apply to this case as well.įirst a small clarification: the listeners that are of interest to us are listeners for input events for which the default browser action is to scroll. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |