Is this a Firefox bug, or am I doing something wrong?
Changing the top value of a positioned element many times (for instance while a user drags an other element) works on all mainstream browsers as far as I could test, but Firefox which seems to debounce these changes.
Here's a working example under Chrome:
And a failing one under Firefox (notice that the attribute is updated in the dev tool, but the page stays out of sync until the events stop being fired):
You can try it at http://ec2-13-58-57-41.us-east-2.compute.amazonaws.com:8080/components
Quick note:
You might tell me to just use the browser's scroll so here's my reason for doing what I described:
I find it practical to have a Scroller React Component wrapping content:
it makes it easy to control the style of all of my scrollbars for any browser, depending on a theme and on the state of the application (like displaying them only when the content is hovered for instance)
it provides a single development interface for regular scrolling and virtual scrolling
Related
I am currently developing a hybrid mobile app which makes use of -webkit-overflow-scrolling: touch; on the "content area" to provide smooth scrolling.
I have hit somewhat of a road block however when using this feature. Upon scroll (I check with an .onAnimationFrame loop) I check the .scrollTop position to see if any movement has occured so that I can let various components within the application know of this so they can perform certain actions (Use case examples may be parallax scrolling, controlling culled rendering etc.). This is all well and good when testing in a desktop browser (Ie. Chrome 41) however when debugging within iOS Safari OR iOS UIWebView the scrollTop position seems to be cached when there is a large amount of movement (Eg. a user flicking the view)
This caching means that other elements expecting to know the exact current scrollTop value will fall behind and the view becomes out of sync.
My presumption is that overflow scrolling forces rendering onto the gpu so I'm wondering if there is any way to get around this or to force invalidation of the cached scrollTop value.
DEMONSTRATION: http://jsfiddle.net/skpmkjea/ (load up in safari on an ios device and connect to debugger to see console log of scroll top positions)
Things I've tried:
Forcing an empty element in and out of the root body to try and force a full page update to re-calculate the scrollTop value
Using a container div within the scroll element and checking for the bounding box updating .getBoundingClientRect() but this seems to have the same cached values
More info (I'll add more if it would help anyone):
UIWebView build with Cordova
My main test target is iOS7
The issue exists but is much less noticeable (ie. cached value invalidation appears to occur at intervals) on android 4
I am trying to debug this and can't make any headway. I've got this HTML5 JavaScript library I am building and the test page for it can contain large volumes of output as I am piping console.log and exceptions out into the DOM to quickly inspect them on mobile devices (it is the only way I know of inspecting state on an Android device for instance)
Here is the page. So long as I don't push up broken code while I work on this you should be able to produce plenty of debug output which will be pumped into the <body> thus allowing the page to scroll. Note also to toggle the visibility of the big blue debug panel you can tap the header text at the top of the page (like a button).
The issue is specific to iOS: Tapping the iOS status bar does not work in either portrait or landscape modes, and I am not sure what it is I have done with JS or otherwise that has disabled this quite handy feature.
Use of -webkit-overflow-scrolling: touch appears to be the culprit for iOS6 here. It actually looks like iOS5 is less broken w.r.t. this issue.
I think there may be a way to work around the issue by dynamically setting -webkit-overflow-scrolling: touch on the elements that need it by catching touch events on them. Or just leave it off as they still remain usable (just have no momentum).
I have a page where necessary elements are repositioned over some extra html attributes.
For example:
<div class="contentplate" relativePosition="top-left" relx="1" rely="3" relw="14" relh="8" relFontSize="80"></div>
is repositioned by class 'contentplate'. It is positioned to a raster related on the actual windowsize. It's child elements are processed recursively to get the relative positioning also working inside this containers. All of this works as expected.
The trouble begins when using jQuery('parentcontainer').animate( {left:0},100 ) or something:
in some way repositioning the elements leads, jquery to animate only the parent element and not the childs.
the funny part is after te animation is done, the position of the childs is corrected somehow by jQuery but as told not animated.
All the elements are styled position:absolute, overflow:hidden
and no, the repsotion algorithm only runs if the window is resized, or after the page has been loaded once.
I have 3 Test for you if you are interested:
the site fully dynamically repositioning (animation is failing, except in firefox)
http://www.bourier.org/demos/jquery_animation_failure/test_2.html
a snapshot of a repositioned site without active repositioning (all browsers, all good)
http://www.bourier.org/demos/jquery_animation_failure/test.html
a fully dynamically repostioning site with a yellow grid you can see enabled
http://www.bourier.org/demos/jquery_animation_failure/test_3.html
a screenshot where you can see the dynamic page with grid enabled
thanks for your time
As it seems, it is a bug in the browser Engine correlated to usage of a canvas and CSS modifications of div's z-ordered above.
The canvas is there only for checking the grid features are correct e.g. debugging purposes.
I removed the canvas and everything is working now as expected.
There is something very wrong, can be shown here using the chrome developer tools:
The elements are detected in the correct position by the debugger, and mousepointer, but they are not displayed there. very odd this.
i don't want to digg deeper than this, but in my opinion the Firefox behaviour is correct and Chrome and Safari are doing something very wrong.
If i should post a issue report to chrome developers leave a comment and i will.
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.
I've got a div that I want to position at the bottom of the mobile browser (Safari + Android) viewport. Currently my div is fixed at the bottom on all the top 5 browsers on Windows (IE, FF, Saf, Chrome, Opera), but that's "the browser window", not "the viewport".
On mobile devices (I've only tried on Samsung Galaxy Tab with Android 2.2 so far) the div appears at the bottom of the page, but if you pinch/punch to zoom in, the fixed div doesn't follow. It stays behind, outside of the viewport.
I'm specifically using the position:fixed and bottom:0 CSS properties to maintain the position, and as I said, it works fine on a non-touch browser.
Am I going to have to resort to keeping the div in the position I'd like it to be (at the bottom of the viewport) by hooking into the touchmove event and looking at (a) the zoom level, (b) the viewport position, and (c) the scroll position?
I'm using JavaScript to inject the div into the page rather than using inline CSS. The good thing is that I don't have to worry about quirks mode (as I'm only targeting Webkit browsers), so that's one positive thing.
I can't set doctype, use inline CSS or inline DIVs. Everything has to be added dynamically via JavaScript. Here's what I've done in my test so far:
var mydiv=document.createElement("div");
mydiv.style.position="fixed";
mydiv.style.bottom="0px";
mydiv.id="floater";
mydiv.style.width="400px";
mydiv.style.height="50px";
mydiv.style.backgroundColor="yellow";
if(document.body)document.body.appendChild(mydiv);
document.getElementById("floater").innerHTML="HELLO";
Your position:fixed won't work on mobile webkit browsers. Take a look at the mobile webkit fixed position problem on http://www.position-absolute.com/. They have a few ways of keeping something at the bottom.
Check out iScroll:
http://cubiq.org/iscroll-4
It seems to be one of the better options out there - definitely worth looking into.
I have used the previous version of iScroll but unfortunately there were a few things that didn't work to standard so we had to scrap the idea. However, the guys at Cubiq have just released v4 of iScroll which promises to fix a lot of the things that were issues in the previous version.
Best of luck!Dan