After a css3 transition being done, a callback makes the inner elements to be visible (using universal selector and opacity property).
In the following case, they stay invisible from the screen. The strangest thing is that when using the console and "inspect the element", they magically appear.
http://jsfiddle.net/tT84s/12/
This bug happens on Chrome 19.0.1084.52 but not on Safari 5.1.5
I'm suspecting a rendering bug, some internal browser triggers which doesn't fire or something like that.
-webkit-backface-visibility: hidden
Webkit Bug. Try using the code above, it may help with your problem. Also you might want to use transform: scale() instead of width and height.
Try http://jsfiddle.net/tT84s/13/
Shaking the DOM seems to work. In this fiddle, I re-append the transitioning element's children (in the same order they were originally positioned). It seems to work in the fiddle - though some solutions mentioned here didn't work for our specific experience of this bug.
Generally speaking, it looks like forcing a DOM change works. Note, however that inserting and removing a <div> had no effect. Go figure! Good luck, and everyone please try to post your working solutions for this or related fiddles/bug-demonstrations. For example, this may work with simply adding and removing the last child - to avoid doing more appendChild actions than necessary.
Related
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.
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.
EDIT: This question has been solved. #jerome.s comment helped me narrow my search, read the edits at the bottom of the question.
I found a problem than only affects Chrome (tested on Chrome, Firefox, Safari, IE9/8/7), but what really is driving me crazy is that it doesnt happen on all sites.
Giving a background to the container of a radio input causes a small white background box to appear on the input, however this background is not being added by any CSS, i created a fiddle using some code i found on twitter bootstrap page:
Fiddle depicting problem: http://jsfiddle.net/DMFca/1/
Alternative code to replicate problem:
<div style="background-color:lightblue">
<input type="radio"/>
</div>
Result of the fiddle on my Chrome (25.0.1364.172 and 26.0.1410.43):
The problem is that the code does not behave the same way in bootstraps site (http://twitter.github.com/bootstrap/base-css.html#forms) after i add a background to any of their forms containing radio inputs. I have some other sites where this problem does not happen.
I have tried disabling all CSS affecting the radio and its closest containers in an attempt to discover the "fix", but it continues behaving differently (correctly) despite no CSS applied to it.
Once all CSS had been disabled i compared the computed styles of the input to my own problematic input and they are exactly the same, leading me to believe that it could be the doctype, some magic meta tag or some strange behavior on the container affecting the input, but no success there either.
This problem can be easily replicated, and i do know of some instances where it doesn't happen (so i assume there is a fix), however i cant find it. The same browser and (apparently) the same code have different results.
PS: I found a bug report for Chromium describing a very similar behavior, but relatively old and supposedly fixed
EDIT: Updated chrome to 26.0.1410.43, problem still exists
EDIT2: Viewing the fiddle outside of the iframe seems to fix it, but my initial issue still exists, will try to replicate the problem again and update the question
EDIT3: After seeing that the iframe was causing its own different bug i focused on trying to figure out what exactly was causing my original problem, i ended up disabling every css rule affecting the radio input and all its parents one by one until i found the culprit:
body {
-webkit-backface-visibility: hidden
}
This "fix" to a bug (Webkit text aliasing gets weird during CSS3 animations) causes my bug.
It looks fine on chrome on mac... Perhaps you could try to set transparent on input elements?
input {background: transparent;}
http://jsfiddle.net/DMFca/2/
Despite the fact that a bug seems to exist when displaying radio inputs inside iframes (as mentioned by jerome.s) my own problem was being caused by a fix to a webkit text aliasing bug:
body {
-webkit-backface-visibility: hidden
}
This "bug fix" can be found here: Webkit text aliasing gets weird during CSS3 animations
Once this line was removed the problem was solved and the behaviour identified in the link above was not detected.
I had that problem once. It was... painful!
My problem was an incorrect overflow: hidden applied in a parent.
Try to move your radio node using Chrome inspector level up per level up to the root, so when you see that its ok it will mean that the problem is located in the parent level you quit last time.
I have a top layer with a transparent background image set and would like all pointer events to be ignored. So originally I had this set up with <div style="pointer-events"></div> which worked great, but then I find out that IE doesn't support this.
Further reading I find several places that says IE does support <svg> with pointer-events:none, but I can't get it to work (I've never used SVG tags before so I could be doing this all wrong).
Please see this very simplified fiddle of what I'm hoping to achieve. http://jsfiddle.net/AGVTM/
The root (top most) <svg> element will not support pointer-events: none. The reason behind this is that it's a possible security exploit, you could cover a Facebook Like button with an SVG and let clicks go through as in this example http://jsfiddle.net/rVxTn/
If the SVG element is not root then clicks should go through. This example should work on IE9 (untested)
http://jsfiddle.net/DLEsn/
However, this doesn't solve your problem, because you cant put HTML elements inside the SVG element.
I've encountered this problem multiple times before, I've had to work around it in different ways. I'd suggest you to open a new question with the actual problem (and possibly screenshots) to see how this can be worked around.
Root cause
Absolutely positioned SVGs will not propagate clicks through to HTML elements in IE9.
See this webkit test case discussion: REGRESSION(r66731): pointer-events are broken in some cases, and the corresponding minimal test case. Meaning, interestingly, this bug almost made it in to WebKit, too, but got fixed in time.
In IE 9's case, the results:
IE 9.0.8112.16421 = fails test 1: floating; passes test 2: inline
Workarounds
See this StackOverflow post on simulating pointer-events: none—How to make Internet Explorer emulate pointer-events:none?
They are discussing non-SVG front elements in particular, but the technique of forwarding clicks through to the underlying elements may apply in your case as well.
Has anyone seen the following rendering bug in google chrome:
bug http://community.mediabrowser.tv/uploads/site_1/126/annoying_rendering_bug.jpg
I get it occasionally when I navigate to http://www.mediabrowser.tv
What causes it? Is there any workaround?
I can't reproduce this right now, but I've seen similar in the past. Generally this happens when the element with the background is not full height.
Be sure you are applying the background to the body (which defaults to height 100%) and that you are not applying styles to the html tag (which would throw off the body rendering).
Try inspecting that white bit when next it happens. You might gain more insight into what's going wrong.
Another possibility is that the page hasn't finished loading the GA code at the bottom. If your script blocks at the end of your page take too long to execute you might see this before the closing html tag is rendered.
Possibly related: Chromium issue 5388
omitted close tag...
It is possible that a closing tag was omitted.
I'm running Google Chrome as well, on Windows XP and I am not having a problem with the Rendering. Try closing your tab and reopening sometimes it has a caching type of error like most browsers do occasionally.
Part of the problem lies in specifying a height for the container while floating elements inside. Parent elements are never to expand to contain floated children. The only thing preventing this from collapsing altogether is the p element inside the last div. I'm not sure Chrome is doing anything wrong though Firefox is different but I don't have time to look at it further right now.
This could be the reason, <div style="overflow: auto; height: 400px;"> if you forget adding overflow: auto to your style or somewhere in your stylesheet that truncation happens. IE can accomodate that, but not Chrom and FireFox. Some default height is necessary but not sufficient. W3C validator pass the code without that elaboration since it does not consider the semantic (logical) errors.