I want to implement a jQuery Mobile application without browser history navigation (feel free to ask why). I can generate pages on the fly, insert them into the DOM, and bring them up with changeHash set to false, then clean them up in the pagehide event handler, and all is well in the world. Until I use a widget like selectmenu that invokes a dialog. The dialog's close function explicitly invokes window.history.back(), and my world implodes.
Is there a simple workaround for this issue?
If not, should jQM be adapted to gracefully support nav-less apps, or is jQM fundamentally unsuited for this kind of application?
http://jquerymobile.com/test/docs/api/globalconfig.html
Try setting hashListeningEnabled to false
I learned not to use changeHash=false for this purpose. Make sure that the current page is always at the top of the history stack. In my case, it's the only item on the stack except when dialogs are invoked. So far, this seems to be working like a champ:
function showNewPage($page) {
$page.appendTo($.mobile.pageContainer);
$('.ui-page-active').bind('pagehide',function(){$(this).removeWithDependents()});
$.mobile.changePage($page);
$.mobile.firstPage = $page;
}
The new page is created without a hash, so the URL never changes. Since I'm actually replacing the first page, I had to update $.mobile.firstPage. The call to removeWithDependents() instead of remove() cleans up the dialogs that are created by selectmenu.
Fortunately, it's a lot more concise than I anticipated, just a bit of a pain for a newcomer like me to piece together. I've seen a few comments advising not to "hack" jQM in this way, but I think there's way too much value in jQM to constrain it to a traditional server-dispensed presentation model.
Related
Given a Vaadin application where a user can add and remove elements of a list that is also rendered in the browser, I am wondering what the most efficient way of handling such manipulations would be. Currently, I am simply using the add and remove methods.
I am only experienced with Apache Wicket where one should avoid to manipulate the component tree for performance reasons. In the documentation, I only found a section on how to handle repeated elements in Polymer but nothing on how this can be done using the "simple" API.
Am I choosing the right approach?
The Vaadin UI code runs on the server, so the add/remove operations don't affect the DOM directly. When a response is sent back to the browser, Vaadin will look at the difference between the previous UI state and the current and send appropriate instructions to the browser client to update the DOM. In this case, the instruction would be something like "remove the following components:...". The actual DOM manipulation is handled by Vaadin, and is not something you can affect yourself.
If you run into performance issues, help us out by filing an issue ticket on GitHub, so we can take a look at it https://github.com/vaadin/flow/issues
I've searched for this specific issue here on StackOverflow and the various Apple/WebKit bug reporting systems but have yet to find it specifically cited (which just doesn't seem possible).
The problem:
On our payment page we have various form fields (inputs & selects). For PCI/security purposes we have an iframe that serves the credit card number field (the iframe only has that one field - nothing else).
The issue is that for just iOS users, they sometimes cannot put the focus on the credit card number field. There appears to be 2 different, but related iOS webkit bugs. See the UPDATE below.
If they simply navigate down from one field to another, it usually works. But if they bounce around fields, they can get into the scenario where try-as-they-might they cannot get the focus into the credit card number field it doesn't look like the credit card field gets the focus (appears to be a rendering issue).
Initially we thought maybe there was JS or some invisible DIV getting into the way, but I eventually was able to create an HTML-only example to recreate the problem. (Instructions on how to recreate the issue are on the example page.) Linking to codepen requires I include some code:
<iframe src="iframe.html"></iframe>
I've consistently been able to recreate this issue on iOS 10-12 devices (an iOS 9 device didn't seem to have the problem).
For posterity I'm going to supply the work-around I came across in a separate, but semi-related WebKit bug. However, I was wondering if others out there had stumbled upon this problem and discovered other work-arounds.
UPDATE:
After digging in further I've discovered we're suffering from 2 separate bugs. The first is mostly as I describe above, but seems to be more of a rendering issue where iOS doesn't look like it's putting the focus on a field. However, if you go to the codepen example new example I setup and follow the steps, even when it doesn't look like the field has the focus, if you type the text will render correctly.
The second problem is less likely to happen but is more detrimental. It requires 3 criteria to trip:
The iframe's source has to be cross-origin
Parent page is attaching an event listener to either touchstart, touchmove or touchend (even as simple as an empty function call)
The iframe’s field is off-screen when a different field has focus and the keyboard is present.
The result of these 3 things is that the user cannot place focus on the iframe field at all (typing goes nowhere although document.activeElement shows the last parent page input having focus). Reestablishing the ability to get the focus in the iframe can be difficult, generally need to have a parent page input that can be focused while the iframe field is visible then the user can move their focus to the iframe field from there.
If any of the 3 criteria is changed (not cross-domain, no event listeners on those 3 touch events or the iframe is visible), then only the first – less-prohibitive – bug is present.
I will update my "answer" below with this realization as well.
Update 2: The new example I put up shows both bugs in action; the first page is Bug #1 with a link to the cross-origin Bug #2 example.
Problem is resolved in my environment by adding #Ryan L's suggestion document.addEventListener('touchstart', {}); in the IFrame.
This is good as it's very simple to add and is specific to the IFrame, not affecting the container page.
Problem description: cannot 'touch' (select, edit) another form field on Safari running on iDevices (phone & pad) running iOS 12. This only happens on pages in an IFrame where the container page has added some touch events. Very obscure set of conditions that are difficult to debug.
I believe I have found a fix for this frustrating little bug, and like most bugs it's a super simple fix.
All that needs to be done is to apply a the following css to the input within the iframe.
input:hover {
cursor: text
}
Here's an updated example: https://codepen.io/ryanoutloud/project/full/AEKGjj
Now as to the bug itself, the focus is actually on the intended field and any entry from the keyboard will be registered properly. Once typing begins the caret jumps into proper position. The
issue I found with the ontouchstart="" solution is that it simply removes the caret from view entirely once focus is placed on a field.
Here's the work-around I stumbled upon: add ontouchstart="" to each of the form input elements (probably selects too).
This came from one of the work-arounds provided on this WebKit bug related to outer page click events not dispatching properly to an iframe (in the context of zooming).
I have not pushed this to production yet, but initial tests seem to indicate this works. I did have to put this on both the parent & iframe form elements to fully fix the problem. I'll probably leverage JavaScript to attach this to the form fields without needing to add the property to each form element.
Open to any other suggestions or concerns with this approach.
this work for me
document.addEventListener('keydown', function(e) {
window.focus()
$(':focus').focus()
});
I am trying to make my job easier by creating simple AHK scrips to auto-fill certain forms online.
Im not really good at explaining, but hopefully someone will understand what Im saying. The problem is that this website has certain textboxes with dropdown auto-suggestions turned on, and it has a delay when selecting those textboxes. I assume when selecting textbox it is pulling data from some database which is causing delay. Now my question is. Is it possible to turn off dropdown menu on websites or even in entire browser if necessary? I really want to my script to tab-in, wright down whats needed, tab-out without delay.
Autocomplete dropdown lists are just JS scripts. So there is no way, I think, to disable them by clicking checkbox in browser settings.
First, try to disable JS completely.
Also, if only few sites are involved, you could try to find out what JS libraries are used and disable them in browser JS console.
Are you planning to do this via keypresses or via COM?
I imagine that via keypresses you could not avoid focusing the elements and triggering the information lookup.
AutoHotkey can interact with webpages on Internet Explorer using COM (Component Object Model).
COM can launch/latch onto an IE instance, detect if the page is loading/has loaded, navigate to a particular url, and set the text of web elements,
quite possibly without triggering the drop-down lists. I haven't tested if COM can disable elements, it's possible.
Also, Acc.ahk may be able to set the text of elements.
I have quite a big application, sometimes with pretty complicate data being created by the user (on the way to the database the data is being altered a lot). The issue is, that any time I need to alter the code, I get stuck for quite a few hours before finding the problem.
Actions in my app:
User opens the jquery modal dialog
There is a form in the modal dialog
User alerts the data and saves it
About app:
The application contains of one site with a table and several buttons
Each of these buttons open a different modal dialog
Each form submission is handled via ajax -> cakephps this->js->submit
How I wrote the code:
For each modal dialog I created an element
After clicking the button I open the element as a jquery modal dialog
Lots of these modals gain information via for example: "On click/on double click etc" events.
My problem:
Every time I alter the cakephp code which is called by $this->Js->submit I feel like putting a gun to my face and pulling the trigger.
I dont know of any easy way of how to debug variables in these functions (cakephps debug doesnt show anything ofc -> the view of those ajax/php functions are not in the main site)
Dont know if firebug has any features for debugging php, but I dont know of any.
The only thing that works for me a bit is commenting out lines of code and putting an alert in the success like this to maybe sometimes get to the values, but it doesnt feel right.
Being used to write code in c++/java and printing or debugging with breakpoints makes me frustrated, when I use such a modern programming language and try to guess out where the bugs might be..
Most errors:
Mostly null pointers or checking !isset index being accessed, but since I know of no way of printing these errors from modals no checking on the indexes helps me.
Use FirePHP it is a great enhancment of firebug. Works well.
I have a proof-of-concept that is thoroughly and utterly broken here:
http://jsfiddle.net/floyd_may/FAmxj/
I'm hoping the intent behind this is evident. Basically, I want to use #editPage to edit elements on #mainPage one at a time. However, as soon as you click the 'Back to Main Page' button, the main page is empty.
Can I get some guidance here as to how to make this work?
Try using the pageinit event instead of pagebeforeshow: http://jsfiddle.net/FAmxj/11/
With pagebeforeshow, multiple models are bound to #mainpage.