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.
Related
I noticed that Safari in new iOS 16.0 autofocuses an input element if:
type=number or text
pattern=\d*
margin-top on containing element is 48px (I did not test the precise cut-off value here)
Test page: https://www.autoledky.sk/ios.php
autocomplete=off and autofocus=false doesn't change anything. Before iOS 16 there were no such issues. The problem is confirmed on 2 seperate iPhones with iOS 16.
This leads to automatic homepage scrolling, enlarging and opening the keypad, which is unacceptable.
How should I solve the issue without obvious "remove input/pattern".
I couldn't verify the need for any margin criteria. Our scenario didn't match the margins listed here. However I was able to fix our problem on an input[type="number"] field by removing the pattern attribute entirely since it is already a specific field time. By doing so we no longer are seeing the auto-focus in Safari on iOS16.0
I tried many things before finding this topic here and figuring out it was likely a bug, including changing tabindex, disabling javascript, working my way through every plugin on the site we used. Glad to have found someone else struggling with the same issues and having been able to narrow it down a bit more. Thanks!
Just adding my 2cts here, I had the same issue, and the problem was caused by an input element located outside of a form tag.
When wrapping the input within a form element, the issue disappeared; hope this can help someone else.
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.
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'm trying to make a custom checkbox, so I made something like that : http://jsfiddle.net/wQdUn/2/
The problem is that, on WebKit based browsers, the checkbox is toggled only when clicking on the content of the <span>, not on the box itself, while in Firefox I get the behavior I expect.
So I have two questions:
Which one is the right behavior (i.e. the one conform to specifications)?
How do I get the result I want in both browsers (and others...)?
Thanks.
Not sure about the first question, but if you make the span an inline block too, it'll work as you expect in WebKit browsers. See http://jsfiddle.net/wQdUn/5
For those who come to this topic form google:
Safari 6.0.4(8536.29.13) still got this problem, you need to set inline-block on pseudo-element to make click work.
Chrome switched to Blink as it's rendering engine, so this problem didn't happen on chrome any more(26.0.1410.65).