We've got two almost same forms. When it's in div with overflow: auto there is an issue with both selects and inputs, when it's just put normally then works properly.
Two of them on top are working correctly, select on top sometimes also works correctly.
Problem is random:
When you click on field - browser firstly scrolls to top, then a little below field, then a little above, and finally it goes to correct position
Sometimes you can't click on field
Sometimes there is no cursor shown
Or when you are typing anything on keyboard div is scrolling down, even when there is nothing (so after typing a lot of times, you are below content and see just blank screen)
Probably it occurs also on mobile IE 11, but I can't check it.
Anyone had similar issues with mobile IE?
Related
I am currently working on an Ionic 5 and I am facing 2 issues with the keyboard.
When I click on the ion-input and the keyboard appears:
The ion-content is pushed up so it is right above the keyboard, which cause everything to be crammed. I tried a bunch of solutions, but none of them properly worked, and most of them involve android:windowSoftInputMode="adjustNothing", which leaves the ion-content as it is, hence the ion-input is not visible and so the user can't see what they're typing and they also can't see the next button, so they must first close the keyboard in order to see what they wrote and be able to move on to the next step.
When the keyboard is about to dismiss, it leaves a white space in the space it was taking up. It's only for a split second but it is visible and makes the app feel like it's slow or lagging.
These 2 issues seem to be very common as I found questions about them since 2014, and I tried most solutions mentioned in the answers but nothing seems to work.
I seem to be having this issue in this app only, but I know that it is not an ionic 5 issue as people faced the same issue in older versions.
What the structure of the page looks like, I had to close all code blocks so that I could take one screenshot:
android:windowSoftInputMode is ised for native fields (EditText,etc..) so when you click on native xml it will take effect. All what you need to do is in your androidManefist.xml on line applicarion or activity, there is keyboardresize="adjustResize" which is the default, change it to adjustPan and content will not be pushed up , instead keyboard will go up as actionsheet from bottom without effecting the content.
On Mobile iPhone when I click on a input form it gives me the keyboard with up/down arrows to scroll through the form. Once this happens I can jump around the form focusing anywhere, however when a particular select dropdown is chosen it always focuses back to the first form element. This happens on both Safari and Chrome.
Does anybody have an idea why?
It had to do with a label, duh. I had a "for" tag pointing to the wrong element.
Problem solved!
I have an irritating bug with the Facebook like button. When my page is loading, my share buttons (Facebook like, Tweet, +1 buttons) will start on the left side. Then they will appear in the middle of the page. And finally when the loading is finished, they will appear in the correct position on the left side again.
The shifting of the share buttons all over the page is kind of annoying and looks unprofessional, even though they end up at the correct position on the left side when the page is done loading.
I believe this is related to the Facebook like button. I have tested this in IE and Chrome in Windows. I have also tested this in Safari on IPhone. All browsers seem to have the same problem.
You can see the bug here:
http://www.alphabanter.com/
Is there any way to fix this?
I figured it out. Looks like width=450 was causing the problem. I removed width=450 and the Like button now stays on the left side of the page and does not jump around anymore. Maybe there is a deeper reason why width=450 causes problems for my page but at least it works now.
I am building a site that has a header with a fixed position which contains a select menu. The header is supposed to stay locked to the top of the screen due to the position:fixed in css. However, when clicking the select menu in mobile safari on iphone, the header no longer stays locked to the top when the ios select menu opens. It seems that ios is centering the div with the select menu onto the visible area of the screen above the menu. This doesn't happen when the page is scrolled to the top, but when the address bar is not visible, it "breaks" like so. Haven't found any other answers, maybe I'm asking the question the wrong way. I can't post links to code yet, any help is appreciated.
http://selfconstruc.tv/menu-open.PNG
http://selfconstruc.tv/menu-closed.PNG
For now I don't think there is a perfect solution to deal with the focus jumping.
In my case I hide the header on focus in and show again in focus out and it works well.
I don't know if in your case this could be a workaround.
You can try this:
// detect ios device
if(navigator.userAgent.match(/(iPad|iPhone|iPod)/gi)){
// hide header on focus in and show on focus out
jQuery("#content").focusin(function(){
jQuery('#your-header-id').hide();
})
jQuery("#content").focusout(function(){
jQuery('your-header-id').show();
})
}
The #content is a div where you should have all your controls, the jQuery .focusin() detects the focus event on parent elements, so every control will trigger the focus event. You hide the header on focus and show after that. Hope this helps!
I been trying to debug a problem with some odd behaviour inside a UIWebView. My app uses a UIWebView to display a custom form to collect certain information. When the form is first loaded, filled and submitted, everything behaves as it should. After the first submit, when the form is reloaded, the keypad will not display (but the content scrolls as though it is).
The only solution I have come across is here, but this does not seem like the solution to my problem since that line is already in my app delegate.
Is this a known issue? I don't even know where to start looking to debug this issues.
After much searching SO and Apple forums, it was the view hierarchy that was getting rearranged. In my particular case, a progress indicator was being added as new window (by a coworker, so I can blame someone else for this). The trick was not set this new as the key window and only manipulate the the hidden properties
This is just a quick fix because it was only one line of code that was causing this major problem.