I am using iframe-resizer for cross domain application, The Iframe loads fine in desktop and andriod devices but on my Iphone, I am facing below issue:
The bootstrap modal pop ups on Iframe app is hiding and flickering behind when I scroll on page.
I tried
-webkit-overflow-scrolling: touch;
on container of Iframe but that does not work.
Any help/suggestion will be highly appreciated.
We fixed the issue by using position:absolute instead of position:fixed
Position fixed and absolute are somewhat similar in behavior. Both use x,y positioning in the view port and both are outside of the DOM document flow so other content is not affected by the placement of containers. Both require zIndex positioning to determine vertical priority in the view stack.
Position fixed keeps the element pinned at whatever position you set it to regardless of the scroll position of the browser. This makes sense in some scenarios where you actually want to scroll the entire page but leave content in place. The key to remember is to not use it when you build have your own scrollable content on the page.
It turns out in my case I don’t really need position:fixed because I manage the position and size of the container and toolbar headers and footers myself anyway. I know where everything is positioned and keep the content area effectively wedged in the middle of the statically sized elements. By way of CSS and media queries I can force the header to the top and the footer on the bottom using fixed sizes which means I can safely use position:absolute.
Related
I have an html file being served by Express, which also fetches data from an api. When I click a link in the navbar and switch routes (or the page is reloaded), the top navbar moves right, then left, and I can't figure out how to fix it.
If you look at the JSFiddle (link below), you'll notice that I have links to other pages, like /profile, /about, etc. Each time one of these pages loads, the navbar shifts (it's adjusting for the vertical scroll bar disappearing, then reappearing).
https://jsfiddle.net/h7bjyk63/5/
To mimic the api call, I added a setTimeout. To reproduce the issue and see what I'm talking about, you will probably need to run this code locally on your machine, and then refresh the page.
The strange thing is that this issue only occurs when there's some kind of delay (like an api call, or setTimeout). If I remove the delay and immediately load the content, everything works fine.
Some css code is commented out. The only key element I want to add later is position: fixed to fix the navbar to the top of the page.
How do I prevent the navbar from moving around?
The browser first renders the page without the scrollbar because it simply doesn't have to. Then you dynamically add few long paragraphs into the DOM, which makes the scrollbar to appear. This is what's causing your content 'shifting'.
The scrollbar is adding up to the width of your page. To prevent it from doing so, you need to do this:
html{
overflow-y: scroll;
}
I finally found something that worked, although I'm not 100% sure it's the correct way to do things. I just changed the width under the navbar--site-header class to 100vw instead of 100%.
DVN-Anakin's answer helped me understand the problem (and one possible solution), and this answer provided some additional good solutions.
In Chrome 80 the devtools now seems to auto horizontal scroll, to the right, to the content in tree views, but not back to the left when navigating back to a parent node. This makes the Elements tab very difficult to use with Word Wrap disabled. I mainly use the Elements tab to highlight elements to view the styles or to see the the parent/child relationship of the nodes. Word wrap makes it hard to view the hierarchy, because a node with many attributes will just take up all the horizontal space when it wraps. Now every time I click a child element I have to manually scroll back to the left to see the start of the parent nodes.
I don't know if this would be considered a bug, because I could see scrolling to the content useful in some places, but it has made the Elements tab difficult to use. Does there happen to be a way to toggle this feature to make horizontal scrolling manual only, because if I need to scroll I will just use the scrollbar myself.
Update:
This is fixed on canary now. The commits that broke and fixed it are referenced from the issue I reported here: https://crbug.com/1050868
I have noticed on certain websites that are implemented as a single page and free scrolling view in browsers that when you trigger a pop-up or modal window a second scrollbar appears to allow the user to scroll through the content of the window. The primary scrollbar is also active but not very effective since the pop-up or modal window blocks out most of the screen.
I cannot imagine that this implementation approach would have very strong usability reasons, so I was wondering if there is a valid technical reason or constraint. But if there is a valid argument from a UX design perspective then I am also interested in finding out the rationale behind it.
When content overflows (too big to fit in the container element), the browser adds a scrollbar. Looks like in your case, the modal is taking up 100% width/height of the viewport, but it's still too small to fit all the content, hence the vertical scrollbar.
To get rid of the scrollbar, people usually add overflow: hidden on the element which hides the scrollbars, but also doesn't allow the user to scroll. This is fine if the content is not important... such as a graphic that's meant to be a background image or something of that sort.
It's poor design in my opinion. If there is enough content that the user will have to scroll to see it, there's no reason to put it in a modal. If you have a modal, keep it small. In some cases where it's necessary though, you can hide the main scroll-bar when the modal is in view.
At present, when a page is scrolled on Safari iOS 7 (11A4449D) the header chrome reduces in size and clicking anywhere in the bottom 44px of the viewport brings in the footer grey bar (with the next/prev page links etc).
Conversely, scrolling back up the page keeps the footer bar in place and the header bar at the larger size. Is there any meta-tag (or similar) in place to prevent this behaviour of make it consistent on both scroll-up and scroll-down?
We could work around the issue if the browser fired some JS event when the chrome came into/out of view but it doesn't.
Just as an update to this:
We eventually worked around this issue by using bottom: 0; instead of top: 100%; in the CSS. We had wanted to use top: 100% in the first instance as it meant that items being added into that element would be rendered down (off screen) automatically.
By taking the inverse approach we just have to manually translate the area off (using JS) an equal amount as the item being added.
This results in out 'sticky' footer staying above the bottom piece of OS chrome when that appears.
I use the tinyscrollbar plugin on a site in a couple of sections.
So far, it was working great. But now for some reason, the scroll is avaible with the mousewheel but not with the drag/drop slider..
The resolution i'm using is 1360x768, but I test it in a 1920x1080 and the drag WORKS!
I check with firebug if the problem is an overlapping element over the slider but I can't see anything..
I didn't post any code, because I didn't make any changes on tinyscrollbar.js..
If you upgraded to windows 8 there is a bug where it only registers screen touch instead of both the screen and mouse... so you will need to address that
Check the z-index of the scroll bar element places it ontop of everything else (an arbitarily high z-index is fine for this purpose) as this can sometimes end up behind the custom scroll viewport meaning that when you go to drag the scroll bar you click on the wrong element.