I'm working on a jQuery lightbox type plugin that needs to function for mobile devices and desktops. I'm having a problem with the full screen overlay effect. From my research, it seems that the standard solution for this is to use position: fixed or background-attachment: fixed to accomplish the overlay effect. Of course, mobile devices don't support fixed positioning, and so I'm trying to find another way.
Right now, I'm attaching a function to $( window ).on( 'resize' ) to get the new dimensions of the window and set the overlay to them. The problem I'm seeing is that this is triggering flickering scroll bars that make the whole thing really jumpy when I size the window down. You can see the effect here: (http://jsfiddle.net/dominic_p/ZqLCx/3/ or http://3strandsmarketing.com/lightbox.php).
Any idea how I can solve this? The code is still in heavy development so it's kind of a mess, but I tried to highlight what I think the 2 problem areas are in the jsFiddle with a comment that says "THE PROBLEM: START".
UPDATE:
I had a brilliant idea to just change the positioning to fixed for desktop browsers and still rely on my resizing scripts for mobile browsers. It seems to have helped a lot, but there is still some significant flicker when the browser window starts to get small (especially when shrinking it vertically). Also, when using position: fixed on Android 4 there is suddenly a large white gap on the side of the screen that I can horizontally scroll to in portrait mode only. Anyone have an idea of how to resolve either problem?
The solution for the flicker problem seems to be to set the overflow-x (or just overflow if you prefer) property for the <body> element to hidden. For curiosity's sake, it actually wasn't the overlay layer, but the lightbox contents that were causing the flicker.
I'm still struggling with the white gap that shows up on Android, but that's a separate problem, so I'm posting this as the solution.
Related
this might be sort of a random question. I'm developing a mobile web application and I want to give it as much of a native-app feel as possible. My problem is that i have elements on the website that is supposed to be centered both vertically and horizontally in the viewport but Safari's IOS browser snackbar (see picture) is ruining the look and feel.
(OBS this is obviously not my webpage)
The list that appears at the bottom of the browser, is placed on top of the website so that it overlays its content. This is problematic since the element doesn't appear to be centered anymore when this happens.
My question is. Is it in anyway possible to make the snackbar push up/ compress the content of the website instead of overlaying it? I have seriously no idea what to google.
Thank you
So it sounds like you want the minimal-ui property back, but unfortunately Apple has removed this. However all is not lost there are some hacks you can do.
Probably the most popular trick is to scroll down a pixel so safari hides the bars automatically.
Version 1:
window.scrollTo(0,1);
Version 2:
/mobile/i.test(navigator.userAgent)
&& !location.hash
&& setTimeout(function() {
window.scrollTo(0, 1);
}, 300);
The other option is to use a 3rd party plugin like Brim, which can essentially force the screen to rotate orientations and then rotate back extremely quickly.
I'm making a webapp and want to use all the screen and avoid scrolling if possible. There will be buttons that need to be clicked in many areas of the page.
The area at the bottom of mobile safari is not clickable when the tab bar is open and I rotate to portrait and back to landscape.
I have set the body height to the same as window.innerHeight instead of 100% so that I don't have to scroll to get to buttons at the bottom.
bodyEl.style.height = window.innerHeight + 'px';
It may be the case that this area is not usable for interactive content.
Here is a demo with code:
http://plnkr.co/edit/327sUQ?p=preview
You should be able to open a preview of it on iPhone 6 Plus by clicking on the fullscreen button 'Launch the preview in a separate window'.
Update:
It definitely looks like it was a bug in iOS8, it's working as expected in iOS8.4, 9.0 & 10.2 from my simulator.
I may have found an answer to your issue, but would love to hear if you can confirm. Setting the content of your page to have the following styles:
overflow-y: scroll (allows you to scroll below the viewport, but only if necessary per the length of the content; the default value is visible)
-webkit-overflow-scrolling: touch (to smooth any scroll behavior)
in addition to your height: 100% (which forces the content to fill the viewport)
appears to force the iOS menu (tabs and address bar on top as well as nav bar on the bottom) in Safari to always appear. That way, button clicks to the top and bottom of the page are no longer "dead zones" and will actually work instead of opening up the Safari menu.
I'm searching for a solution for a similar problem - this is not an answer, but an attempt of explanation.
First of all - currently, I cannot confirm this behavior - seems like it's fixed in iOS 8.4 (12H143). Didn't know exaclty in which version I saw it the last time.
Nethertheless, I try to explain what I've found out (until we decided to not bother anymore).
The not clickable area is not always a dead zone. If you scroll up before you click, chances are high you get it working. Thus I think the (empty) standard navigation bar is there (height and behavior of the elements are similar/the same), even if it's empty (all element moved to the address bar) in landscape mode.
Btw.:
There's another (similar) problem with the iPhone 6 plus (not fixed yet).
If you have a position: fixed element on the top of a webpage, in landscape mode and only if there are two or more tabs open (and the tab bar is visible), you can click through this element (even through buttons) - as if the whole thing isn't there.
I know this question is a bit old, but since the issue still exists I thought I should share my experience...
As of now there is NO fix for the issue, but there is a workaround. The solution jennz0r provided may work for some, but I didn't like the idea of the menu bar always showing. I saw a website that had the issue solved... well it seemed to work at least. I didn't find anything in their css or js.
So what was the fix? Since the "dead zone" is 44px in height they simply made their floating bar 88px height :D Users would instinctively tap on the top/center of the button and it will almost always work at first try!
Another workaround would be to simply make the button/bar float 44px from the bottom.
"If it's stupid, but it works... it ain't stupid..." ;)
I have an issue I'm struggling to overcome. I deployed my site, and noticed that the viewport logic is broken for STOCK browser on Android device. Chrome browser on the same Android device works. Also, iphone6 works, but iphone5 doesnt. I'm dynamically determing the viewport values depending on width of screen.
Here is a test version of the site:
http://spaniard.ca/workVersions/beta/index.html
I can't change the design and layout, and the site needs to be centered in the middle as it is now.
Does anyone know why on on android stock browser it would NOT work, but on chrome on same device would?
anything will help, thanks!
You would have an easier time doing the responsive layout if the hero image was an actual img tag instead of a background image. You can get the background image to not become cropped by adding the CSS:
background-size:contain;
On a side note, you need to make sure that the containing elements inside article#what-is-spaniard have percentage widths.
EDIT:
From what I have seen, this isn't an issue of browsers, just lacking the proper code
Providing solution without seeing the code is quite tough.
Still giving you a suggestion of resolving it.
Just an idea. Try changing the background size in CSS as below :-
background-size: cover;
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
EDIT: Firefox 2 windows XP
Steps to reproduce problem:
Firefox 2 and visit: http://resopollution.com/rentfox/html/property_setup.html
Begin Typing and pressing [enter key] to create new lines
After about 10 [enter key] presses you'll notice the screen shaking
How this happened
This began happening after I installed a plugin for jQuery. It's located here:
http://resopollution.com/rentfox/html//js/textarea.js
It makes it so the textarea is expandable as I type, depending on how many lines there are in the text area, up to a max-height value which can be specified in CSS.
I tried disabling the 'setHeight' function within this plugin (the only thing that changes height dynamically) but I still saw the screen shaking.
When I think the problem might be
Firefox thinks that the screen just got larger, and compensates by putting in a scrollbar on the right side of the body document.
However, it realizes that in fact the page didn't get larger, and removes the scrollbar, causing the shaking.
I have no idea where in the code that makes Firefox think this way...
Appreciate any help.
You can either force a scrollbar: http://css-tricks.com/eliminate-jumps-in-horizontal-centering-by-forcing-a-scroll-bar/
or hide the overflow of the div and try to get rid of the scrollbar, try overflow: hidden instead of auto in the div propertySetup
Can't reproduce, works fine here in Mac OSX + Firefox 3.5.
I can reproduce it (Debian Lenny, IceWeasel 3.0.6), but only with a very, very specific window size for FireFox (just slightly taller than 1024px, depending on your system font size, window manager and number of toolbars shown).
Just make your page slightly shorter or taller and the problem goes away. The problem only occurs when the addition of a new line after the 10th or so causes firefox to grown the page just enough to cause the scrollbar to appear. Just as you guessed.
That's a tiny 10px margin that is dependent on a lot of browser and system specific settings. In your page that margin is somewhere around the 1024px limit, depending on system font, toolbars, window decorations and the phase of the moon. Move that margin out of the 1024px region. Either make the page 40-50px shorter so that the scrollbar does not appear (even with large system fonts and an extra toolbar) or make it taller so the scrollbar is always there. Zoltan Lengyel's answer in this thread to always force the scrollbar can also be used.
I can reproduce it in Firefox 3.0.11 in Win XP.
Adding overflow:hidden to the body tag seemed to fix the problem, but doing that may wind up causing you more grief then disabling the plugin altogether. Giving the body tag overflow-x:scroll will stick a scrollbar there permanently but seems to solve it, too.
I reproduced it on Windows, FF3.
Interestingly it seems to happen within the jQuery .height() function!
Unfortunately you're using the minified version, so that's as far as I can get.