{"action":"created","issue":{"url":"https://api.github.com/repos/AppGyver/steroids/issues/695","labels_url":"https://api.github.com/repos/AppGyver/steroids/issues/695/labels{/name}","comments_url":"https://api.github.com/repos/AppGyver/steroids/issues/695/comments","events_url":"https://api.github.com/repos/AppGyver/steroids/issues/695/events","html_url":"https://github.com/AppGyver/steroids/issues/695","id":51981375,"number":695,"title":"Bug with keyboard on iOS with footer fixed at bottom","user":{"login":"EdwinRikkers","id":2063535,"avatar_url":"https://avatars.githubusercontent.com/u/2063535?v=3","gravatar_id":"","url":"https://api.github.com/users/EdwinRikkers","html_url":"https://github.com/EdwinRikkers","followers_url":"https://api.github.com/users/EdwinRikkers/followers","following_url":"https://api.github.com/users/EdwinRikkers/following{/other_user}","gists_url":"https://api.github.com/users/EdwinRikkers/gists{/gist_id}","starred_url":"https://api.github.com/users/EdwinRikkers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/EdwinRikkers/subscriptions","organizations_url":"https://api.github.com/users/EdwinRikkers/orgs","repos_url":"https://api.github.com/users/EdwinRikkers/repos","events_url":"https://api.github.com/users/EdwinRikkers/events{/privacy}","received_events_url":"https://api.github.com/users/EdwinRikkers/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/AppGyver/steroids/labels/bug","name":"bug","color":"fc2929"},{"url":"https://api.github.com/repos/AppGyver/steroids/labels/iOS","name":"iOS","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":24,"created_at":"2014-12-15T12:40:31Z","updated_at":"2015-06-23T11:58:02Z","closed_at":null,"body":"Happens on iOS 7.1 in landscape modus, hitting the input field which shows they keyboard makes the webview show the footer (which is fixed at bottom) not fixed at bottom anymore.\r\n\r\nhere is the sandbox repro: sandbox.appgyver.com/sandboxes/926"},"comment":{"url":"https://api.github.com/repos/AppGyver/steroids/issues/comments/114466876","html_url":"https://github.com/AppGyver/steroids/issues/695#issuecomment-114466876","issue_url":"https://api.github.com/repos/AppGyver/steroids/issues/695","id":114466876,"user":{"login":"Leeds-eBooks","id":4380655,"avatar_url":"https://avatars.githubusercontent.com/u/4380655?v=3","gravatar_id":"","url":"https://api.github.com/users/Leeds-eBooks","html_url":"https://github.com/Leeds-eBooks","followers_url":"https://api.github.com/users/Leeds-eBooks/followers","following_url":"https://api.github.com/users/Leeds-eBooks/following{/other_user}","gists_url":"https://api.github.com/users/Leeds-eBooks/gists{/gist_id}","starred_url":"https://api.github.com/users/Leeds-eBooks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Leeds-eBooks/subscriptions","organizations_url":"https://api.github.com/users/Leeds-eBooks/orgs","repos_url":"https://api.github.com/users/Leeds-eBooks/repos","events_url":"https://api.github.com/users/Leeds-eBooks/events{/privacy}","received_events_url":"https://api.github.com/users/Leeds-eBooks/received_events","type":"User","site_admin":false},"created_at":"2015-06-23T11:58:02Z","updated_at":"2015-06-23T11:58:02Z","body":"I hit this problem over the weekend, and after a whisky and a little cry, I set about trying to find a workaround. From my Googling, it's clear that this is not a Steroids issue by any means, but a Cordova one and quite possibly a Safari one.\r\n\r\nMy exact issue is twofold: firstly, `position: fixed;` inputs float way up the screen when the keyboard comes up, and secondly, if the input (`fixed` or not) is anywhere near the bottom of the page, the whole page gets scrolled up so that the bottom of the page is floating about 60 pixels above the top of the keyboard, leaving an ugly white gap in between.\r\n\r\nIn the app I'm currently working on, I have `disableOverscroll` in `app.coffee` set to `true`, so that the app looks like an app and not a website, and I'm using `-webkit-overflow-scrolling: touch` on inner divs to allow scrolling within pages. `html, body {height: 100%;}` on every page. This means that when the keyboard comes up, and Safari scrolls the *page* so that the input remains visible, my pages are not set up to react well to this – they are styled with the assumption that the page will always stay completely still and filling the screen. This is one problem.\r\n\r\nAnother is that I think (without being able to debug the native code) Safari does some funny scrolling with the native rendering layers when the keyboard comes up. I think this is why `position: fixed;` causes problems – it is on a different rendering layer in the browser and this layer seems to get scrolled independently of the base layer, and further.\r\n\r\nBoth of these things probably make sense on a standard web page where the user scrolls the *page* anyway (not just inner divs). In our bastardized web apps, it doesn't make sense.\r\n\r\nMy workaround takes two forms. Firstly, I found a single comment on SO from some saintly person that suggested using `height=device-height` in the viewport meta tag. I cannot do this app-wide, because it messes with my `html, body {height: 100%;}`, `disableOverscroll: true` scrolling system. Fortunately, the viewport tag is dynamic so it can be updated and the changes take effect immediately. So, when I have a `position: fixed;` input, and the keyboard comes up, I use this godawful hack-function:\r\n\r\n```js\r\nviewportFix: {\r\n  set: function() {\r\n    this._vp = document.querySelector(\"meta[name=viewport]\");\r\n    this._oldVP = this._vp.getAttribute('content');\r\n    this._vp.setAttribute('content', `${this._oldVP}, height=device-height`);\r\n  },\r\n  unset: function() {\r\n    this._vp.setAttribute('content', this._oldVP);\r\n    delete this._vp;\r\n    delete this._oldVP;\r\n  }\r\n}\r\n```\r\n\r\nWhen the fixed input is in focus, I call `viewportFix.set()`, and when I'm done with the input, I call `viewportFix.unset()`.\r\n\r\nThis stops fixed inputs going haywire. However, it doesn't prevent the ugly white gap. For that, I have to do something even uglier:\r\n\r\n```js\r\nsupersonic.device.ready.then(() => {\r\n  const kbScrollFix = -64,\r\n    textType = el => ['email','number','password','search','tel','text','url'].includes(el.type);\r\n\r\n  document.addEventListener('focusin', event => {\r\n    const target = event.target,\r\n          tag = target.nodeName.toLowerCase();\r\n\r\n    // A.ios() just does device.platform.toLowerCase() === \"ios\"\r\n    if (A.ios() && (tag === 'textarea' || (tag === 'input' && textType(target)))) {\r\n      setTimeout(() => window.scrollBy(0, kbScrollFix), 0);\r\n    }\r\n  });\r\n});\r\n```\r\n\r\nThere is a slightly ugly little jump downwards as the keyboard comes up, and the user can still scroll up and find the ugly white gap, but it's passable, for now.\r\n\r\nHopefully this might help someone else in the same situation, or even give some hints to the AppGyver team if they think they might be able to find a native solution.\r\n\r\nOne thing I've just thought of – setting the webview background color to the same as my page's background color would also mitigate the visible symptoms of this white gap issue. What is the new, supersonic way of doing `steroids.view.setBackgroundColor()`?"}}