jQuery Mobile 1.0a4.1 iPad Viewport Size - ipad

I just updated the jQuery Mobile version of our client book-in page to the latest 1.0a4.1 and I need some help debugging a window sizing issue off-site (I'm not on location).
The page runs on an iPad at the store so clients can book in their own cases. However, the page is being displayed like it's on an iPhone with huge lettering. "Emulating" with Ripple shows everything as it should, though.
I can't debug it from here and I'm not using any other CSS besides the base 1.0a4.1 stylesheets. How do I force jQuery Mobile to display the page as if on an iPad?
Here is a screenshot sent by the store clerk:

I didn't have the time to test it or try the fix, so it's still a guess, but at least based on your code inspection ;)
ok, so you put a meta viewport in your page and JQM also pops in a little
<meta content="width=device-width,minimum-scale=1,maximum-scale=1" name="viewport">.
As I said - I didn't test it, but I expect a collision. I have read somewhere that JQM was supposed to stop putting those metatags there... Try fiddling with that metatag a bit.
Also - see if the alpha4 or 4.1 release notes (on the blog) say something about viewports.

Running Media Queries

Related

Polymer in Chrome for iOS - it is not working, right?

I was all excited over Polymer and starting developing a web app. I soon found out that Firefox fails loading the site correctly, see this SO post for details:
Polymer: Layout screwed up in Firefox, fine in Chrome
Then, I downloaded the latest version of Chrome on an iPhone 4 (iOS7) and the same thing for iPhone 6 (iOS8) and tried the website. I see the same errors as I see on Firefix (please see the link above).
In other words - going to my Polymer based website using Chrome for iOS fails just as bad as Firefox fails.
So, I'd just like to confirm that this is the case: Polymer does not work on iOS (no support in Safari, no support in Chrome for iOS). Correct?
As I also noted in my other SO question linked above, I was expecting it to work in all browser due to "polyfill", but that doesnt seem to help.
Am I missing something? =)
Note: Using Chrome for Android works fine, no errors there.
As I mentioned in the other thread, it's impossible to polyfill CSS scoping. Chrome on iOS is not actually Chrome, it's built using the iOS WebView (an old one at that), meaning there's no native Shadow DOM and no CSS scoping. The Shadow DOM polyfill does properly wrap DOM API methods like querySelector and getElementById, so you do get limited encapsulation, in that respect. But for CSS, the only thing the polyfill can do is rename your selectors, so :host .blah gets renamed to x-foo .blah and appended to a style tag in the head. It means you need to still write defensive CSS (as you do today) and avoid very loose selectors because they will be applied.
I experienced something very weird today and maybe it might help you.
My firefox was rendering as if polyfills didn't existed.So i went back to false on about:config dom.webcomponents.enabled and it came back to life.
Why? no clue.It worked, so, if you have dom.webcomponents.enabled true on firefox about:config might as well give it a try. IMHO looks like a polyfill bug on capable (yet buggy and poorly supported) web components browsers. worth a try.

Twitter Bootstrap Icon Issues in IE

Bootstrap is a very cool, but for some reason all icons (and icons inside buttons) are not serving up at all in IE 7 & 8.
All that is coming up is a square symbol.
I can live with non-rounded boxes in IE, but the icons are kind of a must. Any ideas?
(if it makes any difference, we're running rails as the platform with the twitter-bootstrap-rails gem.
Thanks!
Make sure you have declared the doctype in your HTML.
<!doctype html>
I assume the icons are correctly served on other web browser and you are using 2.0.4.
You can try to clear the ie cache.
Or maybe http://fortawesome.github.com/Font-Awesome/ (ie7 is supported)
There's a list of issue specific to ie on GitHub : https://github.com/twitter/bootstrap/issues?labels=ie&page=1&state=closed
But don't see any related to your problem.
If none of the answer make sense to you, post some code (jsFiddle would be ideal but since the picture is expected to be in /img it will not works without editing bootstrap.css)

jquery ui autocomplete - suggestions show only once on BB5

I am using jqueryui autocomplete and it works great on desktop and most of the mobile devices - ipad, iphone ,etc. However on blackberry 5, when I type in pis for the first time it shows the suggestions list immediately. when I break see the list and type in additional letter, I dont see the suggestions anymore. I change the text, do whatever and no suggestions until I reload the page and it repeats the same issue again. Should I do anything different with BB5? Thanks
What version of jQuery UI are you using? Blackberry 5 only has limited support for JavaScript 1.6 and this may be why your implementation is functioning oddly. It may be that there is nothing you can do to fix it for BB5 users.

Website not viewable from BlackBerries

We are having some annoying issues with BlackBerry phones. For some odd reason, our webpages aren't downloaded fully by some BB phones and I don't have clue what it could be.
If you have a BB, please try www.safarinow.com.
We are currently mainly experiencing this issue on the BB Curve 8520, but we don't have a lot of BB's around here to properly test. I have used the BB simulator for this BB and also for different models, but of course, on the simulators everything works fine. In order to browse the Internet on the BB simulator, it requires you to have the MDS service installed and I assume this works differently than the live server.
Something strange is that when you change the character encoding (BlackBerry browser menu -> Set encoding), it usually does load the full page...
Any clues? Please help :-)
Some articles I read
http://www.builtfromsource.com/2008/08/27/major-bug-with-blackberry-browser-and-multiple-cookies/
-> This doesn't seem to be the issue
http://www.blackberryforums.com.au/forums/general-bes-discussion/284-request-entity-too-large.html -> We are not getting an error, although page request size might be an issue
Maybe you should add an Encoding tag on your page's header.
Something like <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
This could be an issue specifically related to the browser rending engine. It's a long shot but make sure your HTML validates. The browser on certain Blackberries may be choking on improperly validated HTML.
Validate markup for your site: The W3C Markup Validation Service
The service found 41 errors and 9 warnings. It's worth eliminating as many errors as possible and re-testing.
Alison has some very good advice.
One other thing to look into is the amount of, and specifics of, javascript on the page. Before OS 6 and the Web Kit based browser, support for javascript on BlackBerry devices was intentionally limited.
It turns out that a lot of BlackBerries have Javascript turned off. And even if it's turned on, there is a checkbox for "Terminate slow running scripts" (something like that). We use jQuery Mobile, which is pretty heavy, so that was causing the issues. Ticking both checkboxes solved the issue.

help with troubleshooting a jQuery UI Tabs problem on iPad

I would be grateful for some pointers on how to troubleshoot this problem. Quick summary of the situation:
I have a large document (200K) divided into five main sections of inequal length, each of which corresponds to a jQuery UI tab.
The page works perfectly in Safari for Windows, Safari for Macintosh, Opera, Firefox, Chrome, and IE.
The page used to work on the iPad too but it no longer does, and it's the iPad that has changed, not the page.
On the iPad, the tab-content is now getting cut off. E.g. one of the pages is a glossary that runs from A-Z and the page cuts off at the letter -H-. It used to scroll all the way to -Z-. For some reason, iPad Safari is not giving each Tab the full amount of vertical space it needs for its content.
I've looked at the jQuery UI code for the show tabs and it appears to be changing CSS classes hide/show, but I'm no ninja javascript coder. How do I begin to figure out what's wrong on the iPad when my page works as expected on every other browser?
EDIT: The page seems to be working fine on the iPad2. It could be a caching issue and the page might stop working at some point even on the iPad2--I could only test at the Apple store. But I believe the markup and coding and jQuery ui are essentially OK, and it's a iPad Safari issue.
I can't trouble-shoot myself without the code, but the by far best way to trouble-shoot situations like this is to use a tool called Weinre. Obviously if one browser (the iPad's) is having trouble, you need to troubleshoot directly with it. That's difficult since the iPad doesn't have developer tools, but Weinre can actually give you (most of) that, over the network.
Follow the instructions here, but at the least you need to provide a ~/.weinre/server.properties that contains this:
boundHost: -all-
httpPort: 8081
reuseAddr: true
readTimeout: 1
deathTimeout: 5
That will tell weinre to listen on every IP on the port 8081. Start Weinre (via the OS X runner or with java -jar weinre.jar on the command line.
Then you add a special script tag in the main page:
<script src="http://YOUR_IP_NUMBER:8081/target/target-script-min.js"></script>
After this you start Safari or Chrome and go to http://localhost:8081/client/. If everything went as planned you will see the Weinre interface, which is a subset of the WebKit developer tools.
Now connect to your development machine with the iPad or simulator. If the script tag is correct Weinre makes a connection to the iPad and you have a fairly large subset of WebKit's developer tools at your disposal for trouble shooting. Good luck!
I'm sure this isn't the answer you're hoping for, but it sounds like a bug that should be reported to Apple.
You have a page that works perfectly on every other browser and I think its in Apple's best interest that it works on the iPad as well.
There might be other pages out there that used to work, but now don't, so I would consider this bug to be pretty high priority.

Resources