My clients theme is 100% custom created before it was handed to me. The theme when loaded on an iOS device is flickering when scrolling and then the page resets. This is happening all through out the website, but again is only happening on iOS devices.
I am wondering if someone could help direct me to where i can begin to search and i do apologize with how vague this is, but i am really just looking for advice on where i can begin to look in the .liquid code to try to fix this. Or is this a JavaScript issue?
Thank you for whatever help you can send my way.
SOLVED:
The issue was with google tag manager script. The previous developer embeded the script snippet incorrectly which had an impact only on the iOS mobile for the site. Very weird and very unusual.
Advice:
Be sure to check any 3rd party snippets and embeds that are on a site to make sure they aren't impacting in a negative way.
Related
Since I'm not even sure where and how to start solving my issue I will appreciate every smallest push to the right direction.
So, I need to write an iOS application that would keep track on some events of any or at least some webkit-based browsers, or even integrate my app's "Open with..." item into a browser's context menu.
Is it at least possible?
P.S. yeap, since there's no way to use browser extensions in iOS, I'm trying to find workarounds without need to implement my own browser but rather tiny 3-rd side application working along with some of existing browsers.
I have 2 sites where the Twitter Share buttons stopped working.
Has anyone experienced the same problem?
Here are links to my sites:
http://bit.ly/PMVJeA
http://bit.ly/MQQdYG
Problem seems isolated to IE8, not sure about Chrome...seems okay in FF14
Thank you very much for any help you can provide.
We're having issues at the moment that the new or old twitter version of the "Twitter Share Button" with any version of IE is causing some of the JavaScript on our sites to not execute. (Specifically header related)
After tinkering for an hour or so, I've shelved it. Just used IE browser detection to stop it from putting the Twitter button on IE browsers.
Sorry I can't be of more help - but I get the feeling that this is at Twitters end.
I have seen some iOS apps that use the same tab/window mechanism as mobile safari, but I am having difficulty figuring out how that works. Does anyone know how to do this? Or do you know of a good tutorial?
TIA
EDIT 1
It looks like there are no built in libraries to do this, but if anyone knows about a good third party component I would greatly appreciate it.
Can you tell me if Apple accepts an application that opens an embedded browser with most of the functionality living on a web application on the internet?
I have read contradicting opinions on this, and I have even seen several apps that seem to use an embedded browser for the main functionality of the app. Still I couldn't confirm this.
This way we could correct problems on the application functionality on the server with no need to submit another version of the app, while keeping the ease of release through the app store and the home screen shortcut.
Thanks!
I can't get the exact quote from the guidelines, but I know that Cordova apps are allowed, and updating the web files dynamically without going through a new native app version is also allowed, as long as:
* The updated code runs with the Safari Webkit engine (true for Cordova)
* The main functionality of the app is not changed
You say this is a bad idea because the user can save a bookmark on their home screen. This doesn't seem to me like a reason for something being a bad idea to me. If this is the only drawback then I would say go ahead and do it. Why should I care if someone wants to bookmark to my site? The app will not work very well outside the app anyway. If you have an actual logical reason why this is a bad idea instead of some emotional response then please bring it up.
I am doing this too in my application. I am under the impression that as long as you are pointing to a secure site then it should be okay. Please enlighten me: is there some good reason why Apple forces people to develop applications the hard way? A web application is hard enough without having to deal with some monolithic organisation imposing ridiculous rules on you.
I have a web application that uses TinyMce to allow rich text editing. Some of my customers are desperate to get it to work on iPad (which doesn't support contenteditable and therefore TinyMce doesn't work)
At the moment the only choices I have are:
Disallow rich text editing when i detect the browser is iPad. This is not much of a solution because my app relies heavily on rich text editing
Wait for iPad to support contentEditable
Write my own iPad app. This isn't really workable because it's a big complex app with loads of HTML and javascript and I would have to rewrite it all
Use another browser. As far as I know none of the other browsers support contenteditable either.
I'm really keen to find some workable solution. is there such thing as a rich text editor that doesn't require contenteditable? or does anyone have a clever idea I hadn't thought of?
Thanks in advance
Andy
As of June 2011, it looks like there may be support coming in iOS 5
http://www.tuaw.com/2011/06/08/will-ios-5s-safari-deliver-better-support-for-web-editors/
this observation (that it's working in the beta) has been confirmed by a colleague of mine too.
Write my own iPad app. This isn't
really workable because it's a big
complex app with loads of HTML and
javascript and I would have to rewrite
it all
Not necessarily true. You can embed the working part of your web app in a UIWebView component, which is basically Safari embedded in your app, and handle the not working part in the app (providing content). It would require work for sure, but maybe a lot less than rewriting the whole app for iPad.
At to this point there are no browsers on the ipad that will allow RTE. Actually there is only one phone giving full browser support for RTE (sry, i forgot the name of the phone).
Therefor, i think you almost showed all possible solutions (jv42's suggestion excluded) yourselve.