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.
Related
I have a small MVC app, all this app must do is to take search string parameter via text-box and search the database return the data based on the parameter entered. This app works fine in the two of the browser that I have on my machine, it works in chrome and firefox but goes to complete freeze on IE11, it freezes so much so that it cannot even open developer tools nor respond to any click on the landing page.
I am not even too sure what code should I post because I doubt it has something to do with it and if does go down to code I am not sure which part because like I said it works perfect in chrome and firefox
I tried adding the line <meta http-equiv="X-UA-Compatible" content="IE=edge"> on the layout page but that made no difference whatsoever
Typically inability to open dev tools in a browser indicates that something intensive is running in a background. Try to open dev tools prior to entering URL of your application. Sometimes you can find some request looping forever, or wrong javascript.
I have this fiddle,
but can't make ti work in safari. In every other browser it works without flaws. I have read that safari supports data URI, so , I am missing something? Or is a bug?
I am using a simple
<img src="...">
Often, data in this manner cannot have line breaks, and it appears that your fiddle has them. I would recommend trying this without any line breaks, white-space, etc. I'm not sure why that would differ in Safari, but who knows.
We display a piece of signed XML in a TEXTAREA. The signing takes into account the whitespace, so it is critical that this is maintained.
The user then copies and pastes this into an application that validates the XML... we've not had a problem with this until now... IE9 is rending the text slightly differently.
When I copy it into a HEX editor, I can see that IE9 is rendering newlines as 0xA... put it into compatibility mode (or use IE6,7,8, Chrome, Firefox etc.) and it gets rendered as 0xD,0xA
I guess this won't effect most people, as it looks ok... but for us it is a royal PITA!!!
Anyone come across this, and better have a fix :)
Thanks!!!
Not sure if this is really a fix (and I do wonder if this is a bug in IE9?)
Anyhow, I ended up putting IE9 into IE7 emulation mode for the page in question:
http://msdn.microsoft.com/en-us/library/cc288325(v=vs.85).aspx
<!-- Mimic Internet Explorer 7 -->
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
It works, but now, of course I don't have the IE9 features on this page.
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
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.