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.
Related
Basically, in IE11, when you try to print preview (or print, for that matter) this page (and a few others on this site), the page never renders in the preview pane and the number of pages climbs up infinitely: http://www.greatjakes.com/recent-work/
This bug can also be found on pages like these:
http://www.greatjakes.com/news/
http://www.greatjakes.com/news/kegler-brown-website-honored-as-one-of-the-top-sites-of-2014/
http://www.greatjakes.com/blog/the-disappearing-homepage-traffic-is-down-17-on-homepages-of-law-firm-websites/
I've only been able to experience it in IE11. IE8 is fine.
It is not JS-related. If you remove the JS from the page, it still occurs.
If you remove the CSS entirely, it goes away, but that is missing the point.
If you remove (using in-browser developer tools) the HTML elements within the #content-inner > .page block one by one, you'll find that the page actually prints properly when you reduce the number of elements down to about 5 (3 in some pages).
Other than that, I have no idea what is going on! Any help would be appreciated.
We managed to narrow the issue down to a single CSS rule:
#footer {
display: inline-block;
}
We solved the problem by changing "inline-block" to just "inline" within the print-only CSS - but that won't help others fix their own problem because the bug probably manifests itself based on a number of random circumstances. It seems the key was to narrow down the cause. To do this, I simply deleted chunks of CSS until the page actually rendered in print preview. Once I deleted the chunk that was causing the problem, I restored everything and then worked within the critical chunk and deleted the CSS rule-by-rule until it worked. Once I figured out the exact line that was causing the bug, we changed the rule within the print-only CSS (no need to change how it looked in the standard CSS).
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've been wrecking myself trying to figure out what is going on with this big of html. It renders correctly in latest Firefox, Safari and on chrome canary, but normal chrome renders these weird lines and I have no idea why.
I've create a JS fiddle with an excerpt of my code, it's part of a much larger project, but I'm seeing the rendering issue in the fiddle as well as in my app. I've attached a screen shot of what I'm seeing in the fiddle for reference.
Fiddle
Bug screenshot:
The red middle line shouldn't be there as well as the line to the left of "close". This is just one example, as I mouse over the modal I get lines appearing all over the place.
It makes for a less than stellar question as it's difficult to replicate. Resizing the browser helps to show the error. My fiddle has quite a bit of html and css. I don't expect anyone to actually comb through it and fix the issue. I just want to be thorough in presenting the problem.
I've tried looking online but I haven't been able to find anyone reporting the same issue as far as I can tell.
If anyone has any ideas on what may be causing this, how to fix it or point me to a relevant link/SO question I'd be very grateful.
Things I've ruled out/investigated:
- not caused by something else on the page, as I extracted it into jsfiddle and it's still hapenneing. I also removed the body content using the console in my app and it didn't make a difference.
- I dont think the gradients or transitions are causing it, as removing them didn't seem to have an effect
- possibly/probably related to absolute positioning? When I removed the position absolute on the main wrapper element I didn't see this occuring.
- I read that applying a z-index to these elements might help, but it did nothing for these issues.
TL,DR: Why does google chrome, but not canary or safari, show rendering errors on absolutely positioned elements with liberal use of css3 gradients, shadows and transitions?
When I remove the '-webkit-transform: scale(0.95)' on #vfs_uploader and the '-webkit-transform: scale(1)' on #vfs_uploader.visible, it displays fine: http://jsfiddle.net/cjc343/fzqPT/2/
I don't know how this affects Safari or if it has other implications in Chrome, but it does not appear to otherwise affect the layout in the example.
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.
I have a simple textarea which works in all browsers i.e. I can click inside it and type.
But I can't do this with IE6! I am however, able to press the tab key until I get to the textarea and then I can type in it. But I cannot click it.
What a strange quirk? Anyone know what the hell is going on?!
The source of my form can been found here.
Thanks all for any help
Update
Here is the CSS. Nothing jumps out at me.
Update 2
Annoying, I have narrowed down the problem to this line:
background-image:url(../../images/checkout_fuzzy.png);
I use this setup for all my sites pages, but this is the first page that has text areas in it so I guess that might be the reason why it doesn't like the above. What possible could I change the above to so that it doesn't overlay the textarea.
Solved
A position:relative on the containing div solved my IE6 problem! The problem was that the text area was not clickable due to something (div) covering the textareas as identified by Chris.
I don't know what's going on but I have some thoughts that may or may not be the problem. I would hazard a guess that it might be stylesheet related. Its possible in HTML to have something invisible in front of a form element that stops it receiving a click but I would think that wouldn't stop the input getting tabbed to.
To test if this is the case see if you get the same problem if you don't reference your stylesheet at all. If this allows you to click its something to do with your CSS/layout. If you still can't click then I'd probably try turning javascript off on your browser and seeing what difference that makes...
The HTML looks totally fine to me at a glance but I of course can't see what your CSS and/or javascript might be doing on the page. Best of luck. :)
Not 100% sure if this will fix it, but try setting the 'cols' attribute in the textarea.
Here's an example.
<textarea rows="2" cols="20"></textarea>
IE6 can be a bit fidgety if it doesn't get what it expects.
I don't have a copy of ie6 handy but I do know that ie6 can get real funky with absolute and relative positioning. try commenting out your absolutely and relatively positioned CSS styles and see if any of them are covering your form.