May I present to you ... my positioning hack for Safari on iOS8
-
This hack is best appreciated with stiff drink and possibly a glass pipe
FIX: workaround for Safari on iOS causing crazy composer positioning · discourse/discourse@1bdce81
see: http://stackoverflow.com/questions/29001977/safari-in-ios8-is-scrolling-screen-when-fixed-elements-get-focus
-
This hack is best appreciated with stiff drink and possibly a glass pipe
Oh so like any Discourse development, then? Or is that done after waking up in the gutter in a pool of your own vomit the morning after the stiff drinks and glass pipes?
-
Can someone here explain the hacktasticness of this like I don't do lots of javascript stuff?
-
I'm no JS expert, but I know my way around a callback or two; it looks like this fix is forcing iOS Safari to absolutely position the composer in the correct location by overriding the positioning, rather than leaving it up to the browser to work out where to put it.
-
I find it marginally amusing that browser sniffing is now being used to work around weird iPhone behaviour rather than weird IE behaviour.
Out of interest, does it do weird things if you set the user agent of a desktop browser to iOS Safari?
-
does it do weird things if you set the user agent of a desktop browser to iOS Safari?
It's Discourse, so of course it does, regardless of user agent.
-
I appreciate the iOS fix. Would a similar fix help out Windows Phone and the Android phones that are exhibiting similar issues?
-
Its a different bug on Android / Windows Phone. Basically all touch devices act a little bit crazy when you pop open the keyboard on an input that is in a position fixed panel. There is not much you can do, short of flicking in to "full screen mode". It is however usable, unlike IOS8 Safari which is 100% unusable without hacks.
