I'm trying to debug the integration between my app and Stripe's Elements component library. Everything works fine in sandbox mode, but we ran into a problem on production in the 3D Secure authentication process. This involves loading an iframe, into our app, that contains a form from the credit card's issuer (usually via a technology partner, like Arcot).
The form loads correctly and its buttons are working as expected, but the element (for a SMS one time code) is not behaving. Every time I click on the input, something is immediately pushing the focus back to the element of the iframe. This makes it impossible to type anything in, since by the time I touch a key, the input is not in focus. For reference, it is possible to change the input's value using document.getElementById('enterPIN').value = '123456';
I'm not sure if my app is triggering focus() calls (I don't think so) or if it is some part of the iframe code or even Stripe's. Is there a good way to monitor DOM events and do a stack trace for the trigger of each one?
I tried two tactics. Neither gave an obvious answer, but they did point my search in the right direction.
I opened the Event Listeners panel (in the Elements tab of my browser's developer tools) and removed everything I could find, but it seems that this doesn't actually change the behavior of the page- focus kept being stolen away. Luckily, I also noticed some listeners that were defined by the Material UI library.
I used monitorEvents() to get a few more details, but the src & target values were not much help and event.relatedTarget was always null.
In the end, I found this discussion and realized that my MUI Dialog component was stealing focus whenever I clicked on the iframe triggered by its content. This was easily fixed by adding the disableEnforceFocus attribute.
Related
Recently we implemented the GoogleTagManager (GTM), and certain Jquery UI dialogs are not showing at all (some of them always work, some of them never work, consistently). Unfortunately, I cannot provide sample codes.
When a UI button is clicked that calls .dialog("open") the dialog is not shown but the entire page goes grey (div class="ui-widget-overlay ui-front"). I see in the html that the div has "display:none" style.
If I remove the display: none, the dialog is finally shown, but the form's UI is messed up. Somehow the width of the modal is 300px instead of 1000px, etc. Also, the event listeners from the save/cancel buttons are missing. If I put autoOpen: true on the jquery UI dialog declaration, the dialog is shown, but is still messed up the same way.
I noticed that when I have an adblocker, everything works properly, but when I don't, the bug appears. I also realized that a "fbevents.js" file is in the browser when GTM is used, and if I explicitly disable only this file with an adblocker, the bug disappears.
I also see a facebook.com/tr/ call that stays "pending" forever in the network tab in Chrome, when I click on the icon that calls the dialog("open").
And of course, if there is no GTM, the site works properly.
Do you have any idea what is this bug or how should I continue the investigation? (without updating jquery/jqueryUI or without switching to bootstrap modal)?
Without additional detail is very hard to guess, what causes your problem, but there is one thing, I will try ona first place.
Check, how is your trigger made.
There are some GTM configurations, that steps into link click event processing.
So maybe, there is an event listenning on an A element, that onlky pretends to be a link and GTM is waiting for response.
If this is a true, try to change event listener into just Generic click event (Click - All Elements).
I got lucky. I found a second form that exists for a short period of time, which was facebook related (GTM). I realized that a "xy.appendTo('form')" JS code inserts data into the wrong form... By changing the code to "xy.appendTo('#form1')" the problem is gone.
So a simple appendTo('form') started the domino effect, which resulted in duplicated IDs in the DOM, and messed up everything...
The facebook.com/tr call in the network tab is still in pending state, but I believe that is somehow related to Jakub Kriz's suggestion (I will update my answer soon).
UPDATE:
Even though the GTM debugger shows no trigger has been fired, the GTM sends requests to facebook.com/tr calls every time a "a/a href" or "input type="button"" is clicked. I believe this is a default functionality, and I understand why.
In some cases our website is using these html tags in an invalid way: "a" is used instead of a "div" and "input type button" is used for an icon that opens a modal dialog. If we change these, the unnecessary facebook.com/tr calls will be gone.
But I've got still no clue about the pending state. I believe when I apply the changes I mentioned above, the problem will be gone.
I have a single page application. There is a page with products and on the bottom a link to go to the next page. Upon clicking this "next" link the list of products in the DOM is replaced. While the link clicked has stayed the same and maintains focus from the click. Is it better for me to do something like document.activeElement.blur() is that case? Or should I just leave focus on that as is?
I'm unsure what best practice is as with normal server routed pages the focus would be reset with the page load. But I haven't seen any information indicating manually resetting focus on client routing would be the best experience from an accessibility point of view.
Never ever use blur. It's just bad, random and possibly frustrating.
IN a native application, you should always exactly know where the focus is, and the focus should always be at a precise place; otherwise keyboard accessibility is broken.
If you consider your web application as being a true application, you should observe the same rigour.
So, never use blur, since you don't know at all where the focus is going to move afterwards. If you are going to remove something from the DOM that currently has focus, you should first place it in another place that make sense.
IN your case: clicking on a link, you have two reasonable options:
Leave the focus on the link (reasonable as long as you don't move, hide or remove it from the DOM)
Move the focus at the beginning of the new content that just appeared / has just been replaced
You may ask users of your application which solution they think is the best, or deduce the answer by observing them during a test session.
Let's summarize quickly: whether you are making an old-style website with different pages, and you don't have to matter much about focus, or you are making a real application and in that case you should be as rigourous as if you were developing a native app.
Terribly simple.
I am working on a HTML5 application framework, run by a SAP JEE application server, build for companies and their intranet and extranet sites. It is based on the grid framework "Semantic UI" and besides that contains a lot of (also third party) Javascript.
I am currently examining a bug, where clicking a specific icon in a menu, when the page is scrolled down, makes the page somehow scroll back again upwards.
Since there is this great amount of Javascript around, I am currently struggling to find the JS code snippet, which is causing this odd behaviour.
I've read this post here, and got to know event logging in Firebug and inspecting event handlers in Chrome, but that didn't really help me.
I found out that using:
$(<my Elem>).on('click', function(event){
event.preventDefault();
})
I can prevent the scrolling, but I still didn't discover the cause of it.
Has anybody some more advice on how to find the real cause of this?
This behaviour might be caused by several different reasons. One of them that is often overlooked is links like Some JavaScript Handler.
When the JavaScript handler does not properly handle the event (e.g. by calling event.preventDefault(), the HTML link will be followed in addition to the JavaScript handler. Most browsers handle a link to an empty anchor tag # by going to the top of the page. This can easily be avoided when using an empty href attribute like <a href>Some JavaScript Handler</a>.
This question is based on a misconception, please see this question instead.
Subject
I am trying to create some context menu options via a Google Chrome extension that allow you to modify the contents of editable fields on certain web pages. My extension works perfectly on StackOverflow, where the DOM is nice and simple, but Youtube has been giving me trouble for some time now.
Problem
Many of the editable fields on Youtube are hidden in Iframes, so if I try to access document.activeElementfrom the top frame, I get the Iframe itself.
I am trying to get around this by injecting chrome.runtime.onMessage() listeners into every page.
Then, I can presumably compare the value returned by info.frameURL in the chrome.contextMenus.onClicked() event listener in the event page, with window.location.href in the content scripts to see if the message is addressing the correct frame or not. (See this question)
The problem is that the value returned by info.frameURL does not seem to be consistent.
For example, if you go to the home page and use the main search box as the test element, sometimes the value is simply, www.youtube.com...., but other times it is plus.google.com..... or apis.google.com..... or accounts.google.com... and I am not sure why this is.
Can someone explain why the value returned by the info.frameUrl would not remain constant each time you click the same frame?
I've got a pretty big complicated HTML5 app I'm working on (backbone, marionette, jQuery, underscore, handlebars, bootstrap, etc) and deep within the app is a modal popup with a form in it.
When the modal pops open, the first time you click on any form field the form field de-selects itself. After that first click you can use the form as normal. When the app is ultimately loaded into an iFrame in production (don't ask) the first time you click on any form field or hover over any button, the whole page scrolls down until the top of the div element the form is within inside of the modal is at the top of the page, but after it does this once, it doesn't do it again (confused yet? Yeah, it's complex and layered).
I'm at a loss for how to even begin debugging this problem (thousands of lines of code, two handfuls of libraries).
I tried these:
console.log('bound events: ', $._data(this.$el.find('#RandomFieldID')[0], 'events'));
console.dir($('#elmId').data('events'));
console.log('bound events: ', $._data($('body')[0], 'events'));
But that yielded nothing.
Since this is library upon library upon framework upon framework I'm not even sure where to begin trying to find the thing that has obviously bound itself to these fields, or even if it is the fields that are being bound to or something else entirely...
So, any suggestions on good strategies for how to debug a mysteriously bound Javascript event (with multiple JS libraries and frameworks, which can't be just commented out until the problem resolves because they are relied upon to even get the HTML to appear on the page in the first place)?
And, unfortunately I can't do a jsfiddle or something because, as I said, this is deep deep within the app and I'd basically have to re-create the app inside of JSFiddle (impossible) to link to an example (and, it's not in an external facing site, so, I can't just link to it live in production).
I'm stumped.
Here's how I do it with Chrome.
Ctrl-Shift-J to open Javascript console.
Click the little magnifying glass in bottom left, it lets you select an element with your mouse.
Click an element on your page (it will highlight as you go to it.) It will highlight in the DOM at the bottom and show a bunch of properties on the bottom right.
At the bottom right go all the way past the CSS attributes and stuff down to event listeners:
Pick the event listener you're interested in. It will show you the bound function as well as the exact line of code in what script would be executed. That should tell you what library is doing your crazy stuff.
I find the Chrome debugger to be much more powerful and fast (doesn't lag) compared to FireBug and the IE developer tools. It's highly recommended :)