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.
Related
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 setup a wordpress blog and wanted to add a popup from surveymonkey. To simply test if it gets loaded I added the script within the footer.php before the closing body tag. Then I reloaded the page but the popup didn't appear, I tried the same with an empty html page where it did work.
Then I compared the developer console and it seems that not everything gets loaded. For some reason after the object has been loaded nothing else gets loaded. I even tried to add the script to another project (not wordpress) but it doesn't work either.
I also tried to setup a new collector and added the script tag again to my project. The popup has been loaded, but after I reloaded the page the same happens as before. It does work though when I use an embedded survey, instead of a popup survey.
Here are my results on firefox:
Any page
Empty page
What am I doing wrong here?
Wanted to add in the edit This is the correct answer but also I wanted to give context to why the default nature SurveyMonkey creates here is not good. If the end user activates the survey a single time the fact that it would not open again makes no sense and is a poor user experience.
The user would never know, if they closed the survey prematurely, that there was no reason that the activation of the survey could not be completed again.
SurveyMonkey allows for the survey to be taken again until it is completed and then the survey would explain to the user they have already completed the survey. This is a good user experience and sufficient.
***End edit
Just chiming in here, despite this being an old question. The previous answer is absolutely correct as the Survey Monkey popup will only display once and there's nothing you can do via the Survey Monkey interface to get it to show multiple times in a single browser session.
However, you can resolve this issue by adding the following JS above your Survey Monkey JS code:
<script>document.cookie = 'smcx_0_last_shown_at=;expires=Thu, 01 Jan 1970 00:00:01 GMT;';</script>
This code clears a cookie created by the Survey Monkey pop up that keeps track of when it was last displayed, so it'll display every time the page is refreshed without the need to end the current browser session.
I know this is an old question, but I am posting a reply in case it helps someone else. It appears that Survey monkey limits the number of time the pop up shows to once per browser session.
I have tested in Chrome, Firefox & Edge and I was able to reproduce this behavior very consistently.
If either the embed or the pop has shown up once, the pop up will not show up a second time until you either close and re open the entire browser, or load the page in incognito/private browsing mode. But you will still need to close and re open the private/incognito browser window/tab each time you reload the page containing the pop up.
As of yet, I have not found an option within the Survey Monkey interface to disable this behavior for the pop up survey. Note that the embed survey does not suffer from this.
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.
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.