I have run into a really weird bug. I have an element that the background colors drops off of until you take your cursor and select it.
Here is the page:
http://austinpray.com/test
Here is a video:
https://www.dropbox.com/s/t1f7fnvxslebjwj/2013-05-16%2016.33.21.mov
The video is taken with an iPhone because the issue does not occur when I am using a screen recorder oddly enough. It only happens inside of chrome. I have tried both chrome and a blank install of chromium will all caches cleared and such and this still occurs.
What am I missing? I will update as I do more testing on different devices.
EDIT (05/22/2013):
I did some more research and I found the following behavior:
https://www.dropbox.com/s/7tdz41l89qttmnx/2013-05-22%2017.20.20.mov
The problem seems to arise when animation and scrolling happen at the same time.
I froze the entire site with the issue here: mirror
EDIT:
Example
Here is a stripped down version of my code that actually works:
DEMO
The issue is not present in this one. What is different about the following demo and the code that is causing the issue? I have tried stripping out the parallax background code and that does nothing to fix the issue. I am currently rewriting the entire menu's css to see if I missed something simple.
temporary workaround
After learning a TON about how chrome renders elements (especially fixed elements) I came across this temporary solution:
-webkit-transform: translateZ(0);
I added this to my nav bar's style. This is basically a quirky little hack that does nothing to the page and turns on GPU acceleration. This will have to do for now either until chrome is updated or until I rewrite the entire menu bar functionality. The only downside is that resizing the window suffers a performance hit.
a more elegant solution
After all this research and troubleshooting I figured out that the only real problem is that chrome needs to redraw the element all the way rather than stop at an arbitrary point and leave artifacts. Since the pure CSS solution creates some performance issues I I found an excellent method of forcing the browser to redraw an element via jQuery!
$.fn.redraw = function(){
$(this).each(function(){
var redraw = this.offsetHeight;
});
};
I'm using this on the deployed page and it seems to be working great with no performance hits. I'll keep it around as long as chrome 27 is still floating around.
I also found weird behavior and possibly the root of the problem:
The issue does not occur when I have Compositing for fixed position elements enabled in the chrome about:flags section (chrome://flags/). I am running Chrome Version 27.0.1453.93.
My issue is somehow connected with how chrome handles the stacking context of fixed elements and animating fixed elements as the browser scrolls. This article expands a bit on the changes.
How Chrome handles compositing
GPU acceleration as it related to compositing
As this answer showed up first when searching for this issue I thought it would be helpful to link to another answer that seemed to resolve the problem more fully.
https://stackoverflow.com/a/12023155/2192201
And if you don't feel like clicking through, all that was needed to prevent the artifacts while animating was this one line of css:
-webkit-backface-visibility: hidden
Related
I have implemented a design for my website using scroll snapping via scroll-snap-align documented here and scroll-snap-type documented here.
The implementation works, however on Google Chrome the user must scroll quite "firmly" in order to move to the next section. On the other hand only one "tick" of the scroll wheel is required to move to the next section on Firefox. The behaviour on Firefox is much more desirable whereas the Chrome behaviour feels clunky and unnatural.
I'm wondering if there is a way to adjust the scroll sensitivity on Chrome or something along those lines in order to achieve the same behaviour that is present in Firefox.
I have created a JSFiddle with a minimal implementation that demonstrates the different behaviour across the aforementioned browsers.
Thanks in advance.
EDIT: The behaviour in the JSFiddle (and indeed on my website) has now changed to something different but equally unsatisfactory. Now scrolling down one "notch" on the mousewheel causes the scroll snap to go 2 sections down instead of 1, I have created a new JSFiddle with a 4th section to confirm that the scrolling goes down 2 sections and not straight to the final section. I have been unable to find a reference to the update or change in specification that caused this.
I ran into the same issue described above and so I turned to https://lucafalasco.github.io/scroll-snap/. I've personally tested it on Chrome and Firefox and it seems to work well - that is to say, scrolling with the mouse wheel does not skip sections. I'm not intending to support IE11 so this serves my purpose.
I'm having a weird issue with my company's website. There is a blink when you load, with no CSS applied. I thought it just meant the CSS was delayed, but looking at the loading timeline:
It seems the CSS is applied, then after 400ms it stops being applied and then after ~500ms it is applied again.
I'm unable to see what could cause this kind of issue.
How to replicate:
Go to this site. Press Enter on the address bar (for some reason the problem doesn't appear when simply refreshing).
The problem appears only when cache is not disabled.
Replicated on Chrome and Firefox, doesn't seem to appear on Safari.
Doesn't appear when running as a localhost
Doesn't seem to be affected by presence/absence of adblockers
Found a fix, still haven't found the reason.
The fix:
Move the CSS before the JS in the header. This shouldn't have an effect, but apparently it does in this situation.
The reason:
As far as I can tell, the problematic flow is the following:
1 - The browser gets the CSS from the cache and applies it
2 - The browser for some reason realizes it should use the header's CSS instead, and removes the cache CSS
3 - The scripts (mainly google analytics) delay the CSS loading enough that we can see a bit of no css website
Still don't understand point 2 at all, but the fix works. And I'm paid to make it work, not to understand it, so question closed.
I am creating a complex prototype for a Webapp (I am using Cordova to deploy it to my iPhone), and I am having the following problem:
DOM-Elements (which are not created using JavaScript but are right there in the static HTML-File) are there (they show up in the right size in the inspector) but are not visible. Sometime they are simply not being displayed, sometimes they are partly displayed, sometimes parts of them are shown at a different location. The inspector shows their "bodies" always on the right position.
There is a strange solution: As soon as an CSS property is changed after loading the side (for example unchecking and checking any property of any element in the inspector – sometimes changing a property programmatically also works) they are show correctly. The problem is occurring both in Safari and Chrome but not in Firefox (maybe a Webkit problem?). It’s worst in Safari Mobile (which is were I need it to work the most).
Using the transform: translate3d(0); hack helped at first, but doesn’t anymore – I am using and animating lots of Flexbox-elements. I am a simply asking to much from the browser?
Edit: The problem seems to occur only after I have scrolled in one container. After I have scrolled certain (completely unrelated) elements disappear.
Try one of the following to your animated element.
transform: translatez(0)
or
backface-visibility: hidden;
or
will-change: transform;
In case this is destroying anyone else's life, try checking to see if you're setting display: flex on a button element. I guess you're not supposed to do that although every other OS and browser seems to be okay with it.
After some changes to our site, we are seeing that when certain pages are loaded, the page quickly changes width. This occurs every time on webkit browsers Chrome and Safair, but only rarely on some other browsers.
I have not been able to produce the effect at all on Firefox on Windows, Firefox on Mac, nor IE9 and IE11. It seems to rarely occur on IE8 and IE10. I have not found a pattern yet that causes it to appear on IE8 and IE10.
To understand what might be causing this, it would be good to know if certain styling attributes take an initial value while the page is loading but them assume some other value by the time the page is fully loaded. This could explain what is happening.
I should add that this problem developed after some changes which "should" not have caused this issue. Basically having to do with adding URL rewriting to eliminate duplicate pages. Clearly some side effect is operative.
At the moment we only have the code on development servers, so it would not be that easy to actually see it right now, although that is the obvious first question from a responder. So at this point, the question is more "what generically causes pages to reformat under Webkit."
UPDATE: the problem seems to be traced to Google Translate. When I remove that from the page, the problem goes away. Put it back; problem comes back.
Oddly, it mostly impacts Chrome! IE10 and 11 are exempt, and with even earlier IE versions the problem is much less.
I can readily demonstrate the temporary widening of the page just by reloading the page.
I experimented with trying to put the div containing the translate div instead a container div and setting some attributes on that. So far I have not found something that mitigates the problem.
We have suppressed Google Translate recently because it started adding other junk to the bottom of the page. That other junk is gone but we will continue to suppress it due to this new jumpiness.
I believe there is some clever way to contain the issue, but have no more time for it.
I have confirmed that the issue is definitely caused by Google Translate being on the page.
I've been working in this tooltip library since yesterday. I don't know if this problem is for my sleep or what, but I can't figure what's happening.
The subjacent idea about this tooltip library is simple: The user adds in any HTML element the custom data attribute (I mean data-) with the message that he wants to display in the tooltip, and it has to appear. There are some options to add, like the orientation of the tooltip and if the user wants to "cut" the words inside the tooltip.
Here's an example:
<div data-msg="Hi, I'm a tooltip with a text veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeery large" data-orient="right" data-break="yes">Hover me and the tooltip will show!</div>
Everything is fine with bottom, right and left orientations, but when I add the top orientation, the browser adds a species of "border" at the bottom of the tooltip.. I don't know why, but I can't fix it.
Is strange because in the others orientations the problem don't occur.
You can see the problem in the below image (the first tooltip has data-orient="top" and the second tooltip has data-orient="right".
If anyone knows how fix this problem, I'd like to explain me what happens.
Here's the Fiddle.
Thanks,
Leo!
EDIT: I'm working with Chrome 28 version and my OS is Windows 7.
This is a workaround, not a real solution - but shouldn't have any serious side effects in this case (no guarantees, though, see below). And I have little explanation other than this appears to be a Chrome rendering bug.
Add this to [data-msg]::before:
-webkit-backface-visibility: hidden;
backface-visibility tends to fix quite a few Chrome rendering bugs, regardless of the fact that it actually has to do with 3D transforms - it appears to fix this case too.
The reason that it fixes problems possibly has to do with Chrome using a different (hardware accelerated) transition engine the moment you add anything to do with 3D transforms to your element. This may have performance penalties, which leads us to another non-sensical rule that at least used to improve performance if you run into problems:
-webkit-transform: translate3d(0,0,0);
ETA: -webkit-transform alone actually seems to be enough to fix the problem. Experiment with the two, and see if any of them cause other problems.
There have been reports of -webkit-backface-visibility crashing iOS. So do test it there, and try with translate3d instead - or disable the fix specifically on iOS (and live with the bug if it appears there).
As posted in the comments, here's a more minimal example of the problem - although it sometimes fails to... fail, it should mostly have the unwanted darker border at the bottom:
JSFiddle
The bug seems to be caused by transitions combined with border-radius and opacity. Possibly inline-block and padding have a role in the bug too, but sometimes their removal fixes the border, sometimes it doesn't. I hope the backface-visibility workaround is more consistent.