Response title
This is preview!
Move this topic
What Could Be Possible causes of extremely slow keyboard in IPAD Phonegap APP
in jQuery Mobile
•
6 months ago
One of the bugs that have cropped up in an app I'm working is the following:
1. Page one has a login popup - enter your login information. This page works fine no keyboard slowdown
2. The second dialog on the next page has the user enter some more details and is invoked via a standard JQM popup link.
3. Now the inputs in this new popup have become next to unresponsive and completely unusable - the ipad keyboard sticks and key strokes have a major delay between keystroke character and showing up in the input.
Has anyone experienced this? Any ideas what I need to do to fix this or what problems I need to look at?
I have stripped the page down, and can't see anything that would cause this horrific behavior. I am using the latest version of JQM.
2
Replies(14)
surely someone has encountered this?
Leave a comment on imaginethepoet's reply
I would avoid popups until they have been refined further.
Yes, I found input in a popup impossible on iOS as well.
Use a dialog.
Yes, I found input in a popup impossible on iOS as well.
Use a dialog.
Leave a comment on watusiware's reply
As always a good answer. I'll give that a try tonight. Sad that they have a bit of issues.
Leave a comment on imaginethepoet's reply
So I got in to this a bit tonight. I swapped all "popups" with dialog. The keyboard appears to work fine. The problem now of course is popups were designed to work in a page - and dialogs when closed CHANGE / refresh the page - which I cant have since we are doing some compplex interactions in these popup/dialog windows.
Any other thoughts - I think may have to just search through the popup code and see if there are too many events listening for keyboard input .. or some junk.
Leave a comment on imaginethepoet's reply
A dialog shouldn't refresh the page it was called from.
When you close the dialog, it will simply transition back to the page the dialog was linked from without reloading that page from the server, which it has maintained in the DOM.
I am using a dialog, (exactly the same situation as you, I had intended originally to use a popup) and i do not observe that the calling page reloads.
When you close the dialog, it will simply transition back to the page the dialog was linked from without reloading that page from the server, which it has maintained in the DOM.
I am using a dialog, (exactly the same situation as you, I had intended originally to use a popup) and i do not observe that the calling page reloads.
Leave a comment on watusiware's reply
So I came across this bug specifically related to dialogs last night.
Changing to a new page from a page that has been previously loaded using AJAX (external page) triggers a removal of this external page. This seems completely logical and you can also disable this behaviour using data-dom-cache="true".
the previous page should not be removed from DOM.
I went in and took the code fix that was listed above added it into my jquery mobile js file but still am getting the same behavior. I may just have to debug the popups and see what event is hanging.
What I Am Attempting To Do:
I'm dynamically calling the dialog from an event on the page, trying to collect some data, close the dialog and then show the user the same page, with the new data on the page. - I was using mobilechange page in the javascript along these lines to invoke the dialog, but with no such luck.
$.mobile.changePage('#myPage', {transition: 'pop', role: 'dialog'})
The search for answers continues.
Leave a comment on imaginethepoet's reply
This doesn't sound like what you are doing, though:
What this says is that if you change to some new page from the dialog page, then the page you were on before loading the dialog will be removed from the DOM.
JQM will always keep the "previous" page in the DOM. If you navigate further, then the "previous" page is lost. Unless you navigate further, you can manipulate the previous page from javascript code, and when you go back, you will see that the changes will be there.
If you simply close your dialog, the previous page will still be in the DOM, and will not be reloaded. This is what you want, right?
Changing to a new page from a page that has been previously loaded using AJAX (external page) triggers a removal of this external page.
What this says is that if you change to some new page from the dialog page, then the page you were on before loading the dialog will be removed from the DOM.
JQM will always keep the "previous" page in the DOM. If you navigate further, then the "previous" page is lost. Unless you navigate further, you can manipulate the previous page from javascript code, and when you go back, you will see that the changes will be there.
If you simply close your dialog, the previous page will still be in the DOM, and will not be reloaded. This is what you want, right?
Leave a comment on watusiware's reply
Yeah if the dialog is closed it should keep the page the dialog was launched from in the dom and not reload it.. I'm pretty much grasping at straws at this point to figure out where the issue might be.
Popups were working fine - and then keyboard hell started.
The search still continues. I'll update as I discover more.
Thanks!
I just solved a problem here that may or may not be your issue. I had an event setup using the pagebeforeshow event on parent page. When I closed the dialog, the pagebeforeshow triggered the event created the parent page and refreshed the page. All I had to do was change the event that created the parent page to pageinit. I hope this is not too confusing.
Leave a comment on imaginethepoet's reply
Still attempting to solve this - The problem I seem to be running into is the previous page is modified with our dialog - when the dialog closes though it seems to be refreshing the entire previous page. I'm not quite sure what I'm doing wrong here - But when the dialog is open the user clicks a class value and that class gets applied to the object on the previous page. I've spent about 2 days on this bug now. At least with popups it works, but then the keyboard becomes extremely unusable.
There must be some listener hooking on to the keyboard / input that makes it slow down.
A simple demo:
Leave a comment on imaginethepoet's reply
Exactly what do you mean by "refreshing"?when the dialog closes though it seems to be refreshing the entire previous page
Is it fetching the page again from the server? Did you check with Firebug/Web Inspector?
Or it it simply re-executing any pagebeforeshow/pageshow etc event?
The latter is correct. The page was hidden (while the dialog is shown) and now it is shown again.
Leave a comment on watusiware's reply
What I mean by page refresh is that the pageshow event is triggered when the dialog closes.
In many of my pages I use a pageshow event to load a form for the user to edit. There are links/buttons on this page which open the dialog. When the dialog closes the pageshow event is triggered, the form is refreshed, and all user input changes are gone. With popups, the pageshow event is not triggered when it is closed and my page's state is what I would expect it to be.
In many of my pages I use a pageshow event to load a form for the user to edit. There are links/buttons on this page which open the dialog. When the dialog closes the pageshow event is triggered, the form is refreshed, and all user input changes are gone. With popups, the pageshow event is not triggered when it is closed and my page's state is what I would expect it to be.
Got some help with a developer friend to attempt to clarify that.
Leave a comment on imaginethepoet's reply
JQM is doing exactly what it is supposed to do, and what it does is logical.
When you open a dialog, you are opening a new page, which is replacing the current one. When you go back to the previous page, that previous page is being shown, and, thus, pagebeforeshow is triggered.
When you open a popup, you are not opening a new page. You are just opening a popup over the current page. The current page is still shown. When you close the popup, pagebeforeshow is not triggered on the underlying page, because it never closed.
You are going to have to change your logic to work with the way that JQM works.
When you open a dialog, you are opening a new page, which is replacing the current one. When you go back to the previous page, that previous page is being shown, and, thus, pagebeforeshow is triggered.
When you open a popup, you are not opening a new page. You are just opening a popup over the current page. The current page is still shown. When you close the popup, pagebeforeshow is not triggered on the underlying page, because it never closed.
You are going to have to change your logic to work with the way that JQM works.
Leave a comment on watusiware's reply
I found the problem. The close button on the popups. There is an odd eat event on it. As soon as I removed the
Close on all popups typing was fast!
Leave a comment on imaginethepoet's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to imaginethepoet's question
{"z1474575":[14737000003663028,14737000003663449,14737000003663487,14737000003665131,14737000003665305,14737000003665377,14737000003669559,14737000003673131,14737000003674203],"z7664639":[14737000003663475,14737000003663593,14737000003663907,14737000003671039,14737000003671303],"z2952216":[14737000003667013]}
Statistics
- 14 Replies
- 1690 Views
- 0 Followers
