I have a web page that is having some javascript issues. I have tried looking over everything however I have a username field and when you click it (.focus) it should bring up a pop up. I used firebug in firefox to put break points right then the .focus function is called and it it is not fired even though I do focus on the username field. I have also looked over spelling and everything. Cant seem to find the issue. Hope someone can help. One more thing, this issue is happening in all browsers.
page link: http://aliahealthcareer.com/SignUp
Your page has two inputs with id="username".
Repeating ids is invalid html, but the browser kind of ignores it except that $('#username') finds only the first one so your .focus() handler is bound to that one.
The first is within the "login_response" div that is hidden until you click the "Login" option, so if you click "Login" and then click the "Username/Email" field that appears you'll see that your event handler runs.
You have JS issues on load of that page. JS wont work properly thereafter. You need to fix those first.
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.
This issue has come up for me a few times:
I write some code that handles an event, for example a click. I click the element and nothing happens. Some other code is calling e.preventDefault() before my code has the chance to handle it.
Question:
Is there a way to find the code that is preventing default that i have overlooked?
I usually solve this by running javascript profiler in firebug and looking at every function that is called during the click (not inside jquery etc) that may be doing the evil. There has to be a better way.
I would put a test alert in the function that is supposed to execute, starting at the top and then moving it downwards after each statement. If the alert doesn't execute at the top of the function I would check your HTML element and how you are selecting it. If everything appears to be good, I would search your files using possible element selectors.
I have a onclick event for a href , but if a define a rel the function is not getting called
<a href="http://somewebsite"
onclick="javascript:someFunction('somevalue');"
name="top"
rel="somevalue">testing </a>
If I remove the rel property the onclick is working just fine.
What's up with that?
I'm not sure this is really an answer, but really more of a debugging diagnostic. Plus, it was getting a bit long for use in the comments section.
There are no JS errors for me in either Chrome 7 or FF 3.6.8
There are no apparent unclosed quotes in the anchor tag
While the rel tag is not directly supported by any modern browser (but rather used by search spiders), the consensus is that it shouldn't affect events. In fact, per some user comments, such #James Kovaks, it works fine in his tests.
From the Chrome JS console, the function trackForGA is visible, and executable without error.
Attaching an event with jQuery, and then clicking, fires the event as expected. This tells us the click event is in fact being fired by the browser.
code:
$('#countrytabs li:first').click(trackForGA); // click overview tab
Suggested next steps:
Try other event types, to see if they are affected as well - such as onmouseover.
Begin removing JavaScript that is not related to this particular event. Specifically, the only JS you want to remain is the trackForGa function and the onclick JS. Even remove externally loaded JS, such as jQuery (you can presumably do this on a local test/dev box)
If the problem persists, remove trackForGa and instead just do an alert() from the onclick event.
If the problem persists, run your site through an HTML validator (http://validator.w3.org/)
If the problem persists after fixing validation problems, begin removing unrelated HTML tags and content. Systematically remove items until the click is firing as expected to identify a potential culprit.
Also, you never need to specify "javascript:" in an onclick. The only thing that can follow is JavaScript.
I have a series of select elements in a form on a mobile site. These select elements are inside a scrolling pane handled through JS and CSS3 transforms, so getting a touch/click/whatever event to register on the selects was enough of a pain in the first place. However, I'm now finding, on android only, that even though the selects are getting clicked, and are getting focus- they simply refuse to open. I'm 100% sure that the selects are getting their focus event (through debug), so honestly, I am completely stumped. Without the debug, there are no other focus/blur events on the selects. It works fine on iPhone... any ideas?
I've been banging my head against the wall with this same issue. It seems to be isolated to Android 2.1/2.2 (and maybe 2.0?). The selects work fine in Android 1.5/1.6. I even created a simple page that just changes the select's display style from none to block and the select still doesn't open consistently. Oddly, sometimes after page refresh it might work, then after another refresh it might be broken again. As you stated, focus and click/touch events do fire from the element, so I'm at a loss as to what the issue is.
Sometimes if I zoom the page I can get the select to open, but even then the value selected isn't represented in the select element on the page.
I submitted a bug report to the Android dev team, but even if it's fixed in future builds the problem will still exist in 2.1/2.2.
Anyone find a workaround for this yet?
//---- Update ------
If you use a webkit-transition to show/hide the element, attaching the following event to the element appears to fix the select inside of it:
.addEventListener("webkitTransitionEnd",function(e){
this.innerHTML = this.innerHTML;
},false);
I'm not entirely sure why this works, but re-writing the element to the DOM seems to help for some reason. Tested in Android 2.1/2.2 simulator, EVO4G and MyTouch.
I found the solution in this answer by a.meservy. Here is the answer, copied for everyone's convenience.
In this case the problem was actually caused by jQTouch. To fix it, just comment out these 4 lines in jqtouch.css
Under "body"
/*-webkit-perspective: 800;*/
/*-webkit-transform-style: preserve-3d;*/
Under "body > * "
/*-webkit-backface-visibility: hidden;*/
/*-webkit-transform: translate3d(0,0,0) rotate(0) scale(1);*/
I am working on a site that has loads of legacy Javascript and jQuery includes and there is no documentation to show what is happening when.
I have a specific problem to fix and I cannot find the relevant code that is being executed when a button is clicked. To save me from trawling through (and making sense of) hundreds of lines of legacy script, is there a feature, possibly in Firebug, that will identify what script is being executed when I click on a button?
I believe there is a feature in Firebug's console window called Profile. Click profile, click the button, then click profile again. It should give you what all functions were called in that time. Be warned that if this code includes jQuery, you might get a huge long list of functions because jQuery uses tons in its code. Unfortunately, the profiler will also show anonymous functions, which can really be a pain.
Otherwise, do a search in the code for the button's class or ID and go through them. If you have an id of fancy then you might do a search for #fancy in your code and attempt to find it. That may lead you in a general direction, at least.
You can click Firebug's "Break on next" button (in the Script tab; it looks like a pause button), then push the button that you want to debug.
The next time any JavaScript code executes, Firebug will break into the debugger and show you that line of code.
The break button didn't work for me. Instead I did edit the onclick attribute with FireBug and prepended it with "debugger;" ... then you'll break right there once you click :)
None of the above answers worked for me. I am trying to use Firebug to figure out how a feature on a page is working for a site I have no control over. Here is what worked for me.
First, got the id of the element I am clicking on from the page source, and then get a temporary reference to it by creating a watch (under the script tab):
tmp=document.getElementById("idOfElement")
Next, I assigned the current onclick value to another temporary variable.
oldfunc=tmp.onclick
Next, I defined a new onclick function. Initially I tried putting debugger; as the first thing in the function, but this does not work! So instead, I created an alert:
tmp.onclick = function() { alert("Ok"); oldfunc() }
Now, as soon as I click on the button the alert comes up, at which point I then click the "Break on next" button as outlined in another answer to this question. Then I dismiss the alert and immediately I am in the debugger at the correct place.
In my case, the "Break on next" button did not work by itself, because there are a lot of other events, just mousing over the page was causing the breakpoint to be hit, preventing me from ever clicking the button.
In Firebug you can set a breakpoint in some JS and then you get a stack which will let you know the current function call stack. So if you set the breakpoint in function used by several handlers then you can use this to discover exactly which handler you are in.
This probably won't work if you are dealing with AJAX callbacks and the like though.