In my javascript I use the jquery animate() function to slide tweets automatically.
Code:
function movefeeds() {
var element = jQuery("#Feeds");
var position = element.position();
if(position.left == 2000){
element.css("left", "500px");
}
element.animate({ "left": "-=500px" }, "slow");
}
In every browser to code does exactly what it must do: sliding. But in Chrome it is not sliding always, it is sliding half the time. And even if it slides, left gets really bad values (ie. 584.2132312 instead of 500, 1000 etc.)
Any suggestion would be appreciated :-)
EDIT: Looks like a css issue: chrome (from version 11) seems to have some trouble with overflow:hidden
EDIT 2: See this question
Could not find any solution for using overflow:hidden in chrome.
So I removed the overflow from my css and put some div's with z-index over the tweets to hide them.
Found my solution in this: Question
This may seem like an odd answer, but it's consistent with what I've seen happen in chrome before with animations:
Are you including your javascript after your CSS? Depending on how your page is set up, I've seen Chrome flake out as it's trying to run javascript before CSS styles are loaded, so your animation won't work because it doesn't have the element's position attribute loaded yet.
Related
We are using Mobiscroll on our mobile website and it works just fine, except on one device: My boss' Samsung Galaxy S3 (runs stock Samsung fw and stock browser, but Mobiscroll works fine with Chrome). It looks like the z-index of all the elements get messed up.
It looks like this:
http://pix.toile-libre.org/?img=1350013732.png
Everything is dark and hard to read, and the numbers go over the arrows.
I played a bit with the CSS and removed the transparent background of the page, which made all the colors go back to normal (I was not able to make it go behind as it should for some reasons). But the numbers of the wheels still goes in front of the arrows.
I played even more with the CSS and figured out that the -webkit-transform3d makes the wheels go in front of everything, like if it had it's own layer on top of everything.
After a while, I finally found that the problem is caused because my menu bars have "position: fixed;" on them so they stick to the viewport. As soon as put them to something else than "position: static;", the browser seems to mess up everything, including Mobiscroll.
I need to keep these menus fixed, and there are other elements in the page that will get "position: absolute;"
Any idea how I should solve this? Should I hack the CSS and JS of Mobiscroll to get rid of the transform3d and the background so it appears to work not bad, or is there a better solution for that horrible device?
Please tell me if you need anything else!
Thanks!
It appears that this is an android 4.0 bug. There is a bug report on it here:
http://code.google.com/p/mobiscroll/issues/detail?id=96
I face this problem also.. its sucks.
The only solution ive found, is to use mobiscroll onShow & onClose events, to hide and show this position fixed element which cause the overlays problem (in may case that was the footer that was position fixed).
$(".date-picker").mobiscroll().date({
onShow: function(html, inst) {
var header = $('div[data-role="header"]');
if(header) header.css('position', 'absolute');
var footer = $('div[data-role="footer"]');
if(footer) footer.css('position', 'absolute');
},
onClose: function(html, inst) {
var header = $('div[data-role="header"]');
if(header) header.css('position', 'fixed');
var footer = $('div[data-role="footer"]');
if(footer) footer.css('position', 'fixed');
}
});
I know its kind of late. But this did the fix for me,
-webkit-backface-visibility: hidden
on the div
I've been experiencing an issue in mobile versions of webkit (specifically Webkit 534.46 on iOS 5.1.1 as mobile Safari, and now Chrome for iOS) which doesn't happen on any desktop browser that I've seen. (i.e. the demos below should be viewed on a mobile version of webkit.)
Here is a live example of the issue. The core of the CSS is extremely straight forward. It positions an alphabet index along the left of the page:
#index {
left:0; margin:0; padding:0; position:fixed; top:0; width:3em;
}
The issue happens when an element is fixed position over the top of the body. It is fully able to be interacted with until the scroll changes and then it stops accepting input. If I (manually) jiggle the scroll even one pixel then it becomes active again. The example was kept as simple as possible and does not use any JavaScript. After really hammering on it, I've discovered that it appears that the element thinks it is scrolled but has been visually fixed. In other words, if you click on 'A' then try to click on 'A' again, sometimes you will get a second click in but it will be further down the list. This seemed like a CSS reflow issue to me. I know that mobile webkit attempts to reduce the number of reflows.
Here is a live example of the workaround.
I am able to use JS to force the CSS of the entire document to reflow on scroll (with a throttle which prevents it from happening until 100ms after scrolling) which seems to workaround this issue in the simple example. Unfortunately, this does not help the real world version of this issue.
This is the code for the issue page and the workaround script.
My question is what is happening here and is there a CSS workaround that I am missing? Specifically, I'm curious if any CSS guru can figure out what the layout situation is that prevents the clicks from hitting the correct place on the fixed element? A better understanding might help find a real fix.
Edit: I forgot to mention that the example explicitly forces the viewport to the size of the window. So the user cannot zoom in/out, meaning that the position:fixed should anchor the element to the left side of the window.
Update (2012-09-20): This appears to be fixed in Mobile Safari on iOS 6 (as well as UIWebView). Any workaround should first check to make sure it is on iOS < 6. For example, using CssUserAgent this would look like:
if (parseFloat(cssua.ua.ios) < 6) { /* ... */ }
The answer that actually solved my particular issue was a variation of a solution found in one of #Paul Sweatte's links:
Essentially, a plain div which is taller than the body is added. When it is removed, it causes the body to effectively scroll or reflow. Setting the delay to 0ms between adding/removing is enough to allow the DOM to recalculate without causing any flickering. This was the minimal script I could find which fully solved the problem for all position:fixed elements on my particular instance of this issue.
var hack = document.createElement("div");
hack.style.height = "101%";
document.body.appendChild(hack);
setTimeout(function(){
document.body.removeChild(hack);
hack = null;
}, 0);
Ironically, my original reflow fix (linked to in the question) is now working in my real app, too. Putting a variant of it here in case is useful to anyone else. It can be called on any container element, or if nothing is passed in it reflows the whole document.
var forceReflow = function(elem){
elem = elem || document.documentElement;
// force a reflow by increasing size 1px
var width = elem.style.width,
px = elem.offsetWidth+1;
elem.style.width = px+'px';
setTimeout(function(){
// undo resize, unfortunately forces another reflow
elem.style.width = width;
elem = null;
}, 0);
};
The nice thing about this is that it doesn't require creating / adding / removing elements, just tweaking the container.
My install of iWebInspector is pretty busted right now, but after messing around with jsfiddle and the iOS sim it seems like your hunch is correct - despite being position:fixed, the browser thinks the page has scrolled, and screws up the click targets.
It looks a lot like this is the same issue as iOS Safari: Anchors within a fixed positioned element only work once, which also hasn't been solved with pure CSS. Also related: Fixed position navbar only clickable once in Mobile Safari on iOS5.
Tangentially, and I'm sure it's been noticed already, it's not possible to scroll the left side, so on an iPhone the index only shows A-M.
Looks like this is a known bug:
the core problem is: if the page moves programatically (i.e. the user didn’t cause the scroll) the elements inside the fix element are unavailable.
Use absolute positioning, change the markup, or use one of the hybrid workarounds.
Here's a variation of McKamey's workaround. It avoids reflowing twice, and may help with flickering (depending on your app):
setTimeout(function(){
document.body.style.borderBottom =
document.body.style.borderBottom === 'none' ? '1px solid white' : 'none';
}, 0);
I believe this is better, and achieves the same effect, allowing links to be clickable in fixed footers. Somehow, doing urlbar hiding causes links in the fixed footer to be unclickable until you scroll a little bit. I have seen this too when focusing inputs, and I attach an event handler to all focus events to fire this off as well. I do this with dojo to attach the events.
if(navigator.userAgent.match(/iPhone/i)){
/* The famous iOS can't-click-links until touch fix, I attach onfocus */
query('input,textarea,select', this.domNode).on('focus', function(el){
document.documentElement.style.paddingRight = '1px';
setTimeout(function () {
document.documentElement.style.paddingRight = '';
}, 0);
});
}
I have an HTML page with a fixed-height div which should be scrollable (only vertically). In iOS 5 this can be achieved using:
overflow-y: auto;
-webkit-overflow-scrolling: touch;
The div contains an unordered list with about 10 items.
The scrolling works, but sometimes it scrolls only if I swipe my finger diagonally or even horizontally and not vertically as it should be.
I'm wondering if anyone has encountered this issue. I don't want to think that it is a bug in iOS5, but I can't figure out what I'm doing wrong because most of the time it works fine.
I had exactly the same issue. The problem turned out to be caused by two zero size iframes my site used to track history changes and load scripts. Removing these fixed the issue. I filed a bug with apple, waiting to hear back from them.
Check to see if you have any iframes on your page they could be the cause.
I have found a hacky solution but it needs javascript...
I stumbled upon that problem while loading scrollable nodes via ajax and appending them with js.
I found out that resetting the -webkit-overflow-scrolling property with js saved the day
JS CODE:
var myDiv = $('.myDiv');
myDiv.css('-webkit-overflow-scrolling','auto');
function fn(){
myDiv.css('-webkit-overflow-scrolling','touch');
}
setTimeout(fn,500);
It really sucks that we have to call the setTimeout method but that's the only way I could think of...
EDIT : Watch out for display:none
Webkit overflow scrolling touch CSS bug on iPad
You need to put this css setting in your css file - the one you load using the content_css configuration variable:
body {
-webkit-transform: translate3d(0, 0, 0);
}
The other option is to set the css directly from code on tinymce initialization:
$(tinymce.activeEditor.getBody()).css('-webkit-transform', translate3d(0, 0, 0));
I had the same problem in iOS 5.1.1 and it turned out to be due to an ::after pseudo-element with position: fixed that was on an element that contained the scrollable list exhibiting the "wrong scroll axis" behavior. Details here.
Here's the example: http://jsfiddle.net/sammy/RubNy/
Scroll down in the div container. Then click anywhere in the window to hide the element. Then click once more to show the element. You'll notice in Chrome/IE that the scroll is reset, but in Firefox, the scroll remains how you left it.
Which is the standards behavior, Chrome/IE or Firefox? Should I report this to the Chrome issue tracker?
Thanks in advance for any help on this, and happy new year, and thanks again, and cheers, and stuff. =D
Although I'm not sure which of the two browsers (Chrome or Firefox) is following the standard on this one, I'll blame Chrome for being incorrect for not "remembering" the scroll position. In other words, I favor Firefox's behavior, but I'm unsure which is correct (standardized).
Until someone points out which is correct according to standard documentation, I'll continue to blame Chrome. I'll report this bug to the Chrome issue tracker if I haven't already. :P
You can save current element.scrollTop to some bufferVar before display: none. When display: block you reset element.scrollTop back to bufferVar.
But this approach won't work immediately for some reasons not obvious to me. Use something like this to make it work:
setTimeout(() => { element.scrollTop = bufferVar; }, 100);
I don't know which are right however this works:
var offset = 0;
$(document).click(function(){
if($('div:visible').length) {
offset = $('div').scrollTop();
}
$('div').toggle().scrollTop(offset);
});
I hope somebody has a better solution =/
Its just a quirk in how the browsers render the div when the display changes...
Essentially, the browsers reflow the text when the display property changes...
This causes the same quirk...
$(document).click(function(){
$('div').style.display = "block";
});
If you want the scroll to remain the same in all browsers, the easiest thing to use is visibility instead of display...
i know this issue is well documented but i cant find a working solution from what ive been reading. I have a pretty large site and i want a div to sit ontop of everything else on the site. now ive tried giving the div "position:absolute; z-index:99999;", this will work in everything apart from ie. How can i do this in ie?
You can try:
position: fixed; z-index: 9999;
This will make the div to appear on top of the others. (and follow as you scroll down)
so i tried this jquery script i found
$(function () {
var zIndexNumber = 1000;
$('div').each(function () {
$(this).css('zIndex', zIndexNumber);
zIndexNumber -= 10;
});
});
i added another wrapper around it to check if the broswer is ie before hand. this seems to fix the issue but does mean pages are slower loading in ie as every div is being treated. when the page loads.
This isn't what should happen. Without seeing the HTML & CSS, it's difficult to identify why. Some standard debugging techniques...
Setting the z-index to a very high number should render that element in front of everything else**. If it's not being rendered in front, then something is setting the z-index of the other elements to something higher. This could be set in CSS or by script. The quick check is to turn off scripting. To investigate this, use firebug to find the z-index of the element in front. To find it, edit any scripts, even minified ones, and simply search for "z-index".
It sounds like a quick "back to basics" re-examination of the problem may yeild the cause.
Normally one would use low z-index numbers - 2 is higher than 1, why use more?!? Some plug-in developers have been known to use stupidly high z-index numbers.
.
** IE 6 has a well-known bug where replaced form elements (e.g. select) will 'shine' through. The fix is to put an iframe in front of it.