I have developed a mobile site using Icefaces-mobile framework in that I want to search the things based on area zoomed in on the mobile screen, for this users can zoom in/out & navigates the area but the problem is after doing zoom in/out/navigations 4 to 6 times browser becomes unresponsive. I think it must be problem with browsers capability of handling/execute the javascript(correct me if I m wrong).
I have generated latest API key for map using some standers steps given by google on their forum.
Thanks in Advance.
The stock Android browser does suffer from serious limitations, and it could be device performance limitations, as the previous poster mentioned. But you should also be careful that you're not inadvertently causing a memory leak in your own JavaScript. Are there DOM updates from Ajax interactions being generated during this? Check the Android LogCat messages to see the ICEfaces/ICEmobile logging which will show the updates. Check to ensure that if you're custom function is being re-run that you're not causing a memory leak there. If not, I doubt there's an issue with the GMap code and it's likely just a device limitation. Perhaps also put your gmap code in a separate HTML page without ICEmobile and see if you still have the problem.
Related
Alright so in the link below someone already described my issue that I am encountering.
https://developer.apple.com/forums/thread/699982
Basically means that on bookmarked pages on IOS 15, if you minimize the window. dropdownsoptions will become invisible.
now my client luckily accepts that is something I can not solve. But I was wondering if there are workarounds besides telling the users to close their bookmark after using the webapp. like is there a way to hard refresh the browser in such way after minimizing so the users don't have to close the webapp every time?
Our implementation of Embedded Signing (aka In-Session, Captive Recipient, etc.) is now discovering yet another undocumented limitation. The document and Agreement dialog are loading correctly in the iframe. On the Adopt Signature dialog, however, there should be both a "Select Style" link and a "Draw" link. The latter enables the canvas feature for HTML5-compliant browsers for the user to draw their signature on a touch-screen or even using a mouse.
The "Draw" link does not appear when using IE (version 9, 10 or 11) -- and it is completely missing from the DOM. Chrome and Firefox render as expected. My conclusion is that a script to write the tag is not running. Additionally, other screen elements are skewed, as if an html tag is missing its closure or styling scripts have not completed.
Has anyone else encountered this issue?
Seems like I've heard of others encountering issues with some browser types/versions when trying to render the DocuSign signing session within an iFrame. If you haven't already done so, I'd recommend that you try rendering the DocuSign Signing session within its own browser window/tab (instead of rendering it within an iFrame). In addition to (hopefully) resolving the IE-specific issues that you're currently experiencing, rendering the DocuSign signing session within its own broswer window/tab also provides a much better user experience on mobile devices (due to the limited amount of screen real estate available).
Is there a simple way to trigger a mobile OS's native pop-up/alert/etc. from some form of web code? I'm writing an ASP.NET mobile web page and I'd like to, for example, have the iPhone's UIAlertView appear.
EDIT: What I'm looking for is not the method with which to detect which mobile browser is accessing the site (I already know how to do that). If the code to trigger a pop-up that will look nice in an Android browser is different than the code to trigger a pop-up that will look nice in an iPhone browser, I can simply throw in a switch statement that redirects the user to the pop-up that corresponds with their browser. I'm trying to find the html/javascript/asp.net code which will create a mobile-friendly pop-up, either in general or for the various popular mobile web browsers specifically.
Don't know whether there is any pre-built functionality in .NET that can achieve this, but you can surely write one yourself.
You can write a method, that returns the code for your popup, based on the user OS (simple switch statement should do).
EDIT after taking a short nap:
I believe you should reconsider using popups. They are quite annoying even on desktop browsers and many people block them automatically. Probably every blog about accessibility will tell you, that you should keep mobile version of your website as simple as possible because of various compatibility issues that you can run into.
Instead, try to think about some interesting way to incorporate messages for users in a different and appealing way, that won't disturb anybody.
What I do is use a div popup (that floats ontop of the page) and eighter make a big close button or set at timeout to remove it.
jquery mobile is a good place to start.
Im trying to implement a mini browser in adobe air. The browser should work in the same ways as a mobile phone browser, i.e. fit the width of the website to a certain width(specified within the html component) and leave the height to be scrollable.
I have managed to do a mini browser by using the scaleX,scaleY properties of the mx:HTML component however these make the websites look unreadable.
I have also tried setting the css3 zoom property, and that works fine, but it only zooms out certain elements, therefore messing up the site layout.
My question is: Is there a way to make a mini web browser which shows the full content of the website?
Thanks for your help
Air browser cannot be scaled without have an horrible look (no anti-aliasing).
A few years later but here is what I ended up doing:
The requirement was to show the full website that person B was looking at so that person A could guide them through the site. Due to all the limitations of the Adobe AIR Browser we ended up using IECapt (http://iecapt.sourceforge.net/) within an external process to capture the screenshot and send it back to AIR.
This is all well and good, but IECapt is quite out of date as well so recently we have started to look at the using Chromium (http://www.magpcss.net/cef_downloads/) as an ANE within our application and with that we can alter the zoom and dimensions of the page while still being able to keep it up-to-date.
I wonder why no browser out there has such simple but essential feature. Am I missing something? Is there a technical reason?
I'm tired of all those javascript/flash/java hacks out there ...
There is no technical reason preventing the browser from calculating the total bytes to be sent and then tracking how many have been received by the server (Thanks, Kibbee for your comment). Firefox had a functional upload progress indicator until version 0.9, but that build broke it in 2004.
Reading through the Bugzilla updates, it seems that this feature doesn't seem to benefit enough users to get any traction from the developers.
Users who regularly upload very large files tend to use tools like FTP that are designed for this purpose, so they are not affected.
Adding to flamingLogos argument, you might operate behind a proxy which takes your five megabytes of pure goodness within a second, and then sends it off to the server over a 56kbit modem.
I perceive a wrong progress bar slightly worse than no progress bar at all, and there would be many people for who it would be wrong all of the time.
Yes, it's silly, and for some reason browser makers are ignoring it.
I would strongly dispute that large file users use FTP - hardly anyone knows about that anymore and all the common Web apps require HTTP uploads for video, audio and pictures (e.g. youtube).
Ironic that user participation and media is the key to Web 2.0, yet the main mechanism for user participation is so poorly handled by browsers.
For Firefox there have been bugs languishing for years, such as for a better upload progress display:
https://bugzilla.mozilla.org/show_bug.cgi?id=243468
Get voting! :)
The existing progress bar in the status bar is broken for years - see bug 249338 - and it will let you silently abort an upload - see bug 432768.
If you are using Firefox, you can use the new UploadProgress add-on https://addons.mozilla.org/en-US/firefox/addon/221510/ designed for this purpose, that is displaying the progress of your uploads and an estimated remaining time.
You have to post back to upload a file, regardless of whether or not you are being "sneaky" about it (using hidden iframes, for example); the browser's own progress bar (usually down in the status bar) is the file upload progress bar in that sense, although not exactly.
It's just that you can't easily use that data for yourself, so you have to approximate it with a lot of client-to-server communication tricks.
There's no real technical reason you couldn't have a reasonable progress indicator as you do with downloads. You should suggest it as a feature request to your favorite browser.
That said, I think the main reason there are so many javascript/flash/ajax-based upload components isn't so much to provide progress bars (though that's a nice bonus). It's usually because they want to provide a better UI for selecting the data to be uploaded and to sometimes manipulate the data before uploading. The basic file upload feature that's in the HTML specs results in the "Browse..." button that pops up a file open dialog and uploads the raw file data as is to the server.
Chrome has an upload bar that shows the % of loading.
Or, like Peuchele says, there's also an Addon for Firefox.
The web browser has always been that, a browser of the web. It is a mechanism for consumption. Our ability to upload information through the same portal is somewhat of a hack.