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.
Related
As a quick intro, I'm not sure what the best way to phrase/tag/etc this question is, especially as it's so not really reproducible so I would appreciate any input from the stackoverflow community.
On a couple of different WordPress websites I help manage, I occasionally see HTML link elements overflow their normal inline position - the link text overlaps any text after it, almost like the link is absolutely positioned. However, the links are statically positioned and inline as normal.
The big problem with this is that it's not consistent and I've not been able to reproduce the problem. This makes debugging and tracking very difficult. I work mostly in Chrome on Windows 7/10 but I have had reports from clients seeing it in IE and occasionally in Firefox (all on Windows I believe).
In addition, when I have been able to use the Chrome developer tools to debug this, the problem resolves itself if the browser window is resized or if almost any link css properties are changed. It's as if the browser draws the page wrong the first time and when it's forced to redraw the elements, it does it right the second time.
Is anyone else seeing this problem? Does anyone have any ideas what would be causing this and why it would be so inconsistent?
I've not been able to get a screengrab of the issue happening as it's not possible to replicate but I may update this question if I manage to capture it happening any time soon.
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.
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'm having some CSS issues that seem to only occur in chrome. The site in question is liveinthelead.com, and it's still being worked on so if you notice any other strange problems feel free to let me know, I won't be offended. My main problem is this though:
In all of the browsers I've tested except for chrome the site looks fine. However, in chrome, on the main page, the middle post in the three-post divs are shifted down about 20px. But when I open up the developer interface, they shift back to where they're supposed to be! Maybe it's just a local problem, but here are some pictures of what I'm talking about. If you don't experience the same issue then maybe it's just something weird going on with my computer. Cheers.
When I initially load the page
After I open the developer console
One thing that I noticed is that in your div#three-post you set float:left to div.member1 but not to the remaining div.member2 or div.member3.
That's where I would start investigating the problem. Maybe you should set the remaining two divs to also float left. You may need to clear them afterwards too.
For the sake of convention — and so that you don't encounter this confusions again — use IDs for selecting specific elements, e.g., member1, member2, member3, and use classes for selecting multiple elements that should share the same attributes.
I'm unable to replicate on Chrome 15.
=\ could be a good thing! Try another computer!
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.