I have a page with bunch of 3rd party JS scripts. When I load the page, it scrolls down to a specific div.
I already spent 2 hours trying to find out which code is causing the scroll.
Is there a way to find out which script / part of the code is triggering the scroll?
Wow, was this hard to debug. Seems like the debugger has some missing features, like tracking the emitter of an event.
The problem is WooCommerce. Specifically, it appears that WooCommerce is setting autofocus on the billing_last_name input field. The browser is then automatically scrolling the page to bring the field into view.
One would hope that there is a configuration option to turn off autofocus, but it appears WooCommerce does not provide this.
You can try adding this to your theme
function disable_autofocus_firstname($fields) {
$fields['billing']['billing_first_name']['autofocus'] = false;
return $fields;
}
add_filter('woocommerce_checkout_fields', 'disable_autofocus_firstname');
If that doesn't work, you can create a CSS rule to hide the billing name field and then run a delayed JS function to show the billing name field after the page is fully loaded.
How I debugged it
Per the OP's request, and considering the bounty offered, I will describe how I debugged this.
I'm a little embarrassed that I didn't just say to myself "Hmm, the page scrolls up to a form, the cursor is in the first field of the form, I wonder if it has autofocus set." Unfortunately, I'm not mainly a front-end programmer, and autofocus did not come to mind at first.
I started with the idea that it was being scrolled via JavaScript, either an explicit call to a scroll function or by setting scrollTop on something. I put an event breakpoint on the scroll event and tried to determine where the scroll event was being generated. Although I found the scroll event, I did not find the source of it. All I could determine at this stage is that the scroll event was targeting the document, not something inside it.
I used monitorEvents to listen for events on document and found only 3, a click and 2 scrolls, the last of which was caused by a delayed scroll-to-top function inserted by the OP to work around the first scroll. I put an execution breakpoint on setting that timeout (not executing the function) in an attempt to "divide and conquer", that is, to see if the scroll was happening before or after that. I maintained that breakpoint for the rest of my debugging effort.
The weird thing was that generally, the page would not scroll before it hit that breakpoint, but sometimes it did. I thought that was odd, and although I didn't know what to make of it, it had me on the lookout for something unusual.
I tried searching all the JavaScript for "scroll" and "update" (text) to look for more breakpoints to set, and set a bunch at JavaScript that did scrolling, but nothing hit.
I noticed that there was a lot of JavaScript dynamically updating the page, and thought that maybe the scroll was due to an update of some sort.
I tried putting a jQuery event listener that logged all events on document (since the JS was using custom events not logged by monitorEvents, and I had already determined that document was the target of the scroll event) to emit all the events and see if it was some custom update event. There were a bunch of custom events, and I later generated the events in the console to see if the page would scroll in response. Since I could not get the page to scroll that way, I concluded that events were likely a dead end.
I switched tactics. I looked at where the page was scrolling to, and saw it was scrolling the WooCommerce form into place. So, while stopped at the execution breakpoint (described above), I deleted the entire WooCommerce form from the DOM, and verified that the page no longer scrolled. This had me convinced that whatever the problem was, it was caused by WooCommerce.
Unfortunately, my Google Fu failed me, and I did not immediately find the problem through a Google search. Instead I found how WooCommerce scrolls the page on errors to make sure the error messages are visible. This led me back to the JavaScript.
Still, there was a lot of JavaScript, a lot of it dynamically creating the form (localizing it on the fly), and a bunch of German (which I don't speak), and I wasn't finding any JavaScript causing scrolling. I really wanted to narrow down which JS file was causing the scroll.
Chrome allows you to set a breakpoint on "script first statement" (under Event Listener Breakpoints -> Scripts), so I did that. In addition to stopping at the first line in every script file, it stops at the beginning of every <script> tag on the page. I found this script tag near the bottom of the page
<script type="text/javascript">
if(typeof jQuery == 'undefined' || typeof jQuery.fn.on == 'undefined') {
document.write('<script src="https://www.prored3.de/wp-includes/js/jquery/jquery.js"><\/script>');
document.write('<script src="https://www.prored3.de/wp-includes/js/jquery/jquery-migrate.min.js"><\/script>');
}
</script>
The weird thing about this script tag was that the scroll happened immediately after this script tag was processed, but jQuery was already loaded, so the script actually did nothing. I was also able to confirm via the console that both before and after this script tag (which is before and after the scroll), the DOM was not flagged as ready. This means that all the jQuery ready handlers had not run by the time the scroll happened. That eliminates a lot of JavaScript, and got me thinking about why the scroll happened after but not before this tag.
I guessed that internally, the browser saw the document.write calls and determined that the DOM was not complete until after it passed that tag, but as soon as it was past it, the DOM was complete and it could start processing page-level attributes. That, along with the earlier observations, led me to look at the WooCommerce form more closely and discover the autofocus attribute set on the billing_first_name field.
Oddly enough, I was not able to prevent the scrolling by deleting the autofocus attribute. I don't know why, but I'm guessing it has to do with browser internals and the fact that the DOM was not ready. I was, however, able to prevent the scrolling by hiding the the billing_first_name in put element via CSS, which convinced me it was the cause of the scroll.
Adding "autofocus" to my Google search led me to other complaints of similar behavior with WooCommerce, and combining posts led me to the PHP solution I posted.
Updated
As I don't have OP's page for testing, the following method of finding registered event listener actually DO NOT solve the issue OP is addressing.
However, this is the general method when I want to find a specific event, just reserved for someone's reference.
If I understand your meaning correctly, you want a method to tell you where do the specific events occur. Please tell me if this is not doing what you want.
You can try to add a breakpoint on chrome debugger.
F12 -> Sources -> Event Listener Breakpoints (in list with those Breakpoints, Scope, etc) -> Control -> Click the box of scroll.
For Sure it may captures some other scroll event you are not interested, but you can go through it next by next until you find the one you want.
Besides, there may be also event not related to scroll, you may also need to try focus or DOM Mutation -> DOMFocusIn.
I'm building a chrome extension where I have to access the innerText of some span elements. I can safely get them using simple document.querySelector commands.
But for some spans, it returns null because they don't exist yet in the DOM> (For security reasons, I cannot disclose which website this happens with but to make it more clear, LinkedIn does a similar thing where the Experience block is only loaded if you scroll down to it.)
Now, to quote the problem using that example: I want to get the value of a span which is inside that Experience section. If I run the script inside window.onload, it returns null because the span isn't there yet.
One solution is to simply scroll the page, (or even worse, ask the users of the extension to first scroll the page before running the extension.) However, I do not want to do that.
Is there a way in JS to scroll the page in the background without visual feedback to the user so that I can get the value of the HTML elements that are initially hidden?
Assume that the span I want to get has the following class: defense-rc4
On this page almost anywhere on the page if you copy you'll get the string Read more at http:// added to the end of your copy. I was wondering how. After looking at the source (post-copypaste.js) and setting a breakpoint I didn't understand. That area seems to be firing when i select text.
I tried looking at the DOM (via view selected source in firefox) and I didn't see the text in the dom. So it must be a javascript trick. I can imagine catching a control C event (i dont know if that is what is happening) but i cant imagine how you can add or affect the text being compied in since it belongs to the dom. I don't see flickering or anything
How does that JS trick work or how do i debug it to figure it out?
But the awkward thing is the selection on the regular window/dom doesn't seem to be affected.
It is, but just not visible. What usually happens is there is a container somewhere else on the page (not necessarily visible). The content you have selected is being pasted in there, then extended, then copied and deleted from the container. It all needs a fraction of a second and by the time you paste it in somewhere, your clipboard is already storing the extended content.
If you look closely on the page you have linked in as an example, there is an empty div tag in the body with a class of pw-root. <div class='pw-root'></div> When you copy the text, for a second (visible in Firebug for instance) it changes as explained above then gets emptied again.
I've got a list of data in an observableArray and I want to show it in a javascript dialog window (I'm using jQuery.blockUI if it matters). Unfortunately the dialog seems to come unbound after the page is loaded. The dialog initializes correctly (the data is displayed), but it isn't updating with changes.
There are no Javascript errors and I've moved the binding to after the dialog is generated and added to the document (no effect). I've also tried calling ko.applyBinding on the main div that makes up the dialog but that, for some reason, causes part of the main page to hide (the DOM is there, but they are hidden).
EDIT: I've created a project on jsfiddle that reproduces the problem. The main culprit seems to be wrapping the content of the dialog in a div. If I show the content directly it seems to work (of course I can't do that, the wrappers provide a common style for our dialogs).
I'm recovering from the flu and could easily be missing something obvious, but I've been trying all day and nothing is coming to me. Any ideas?
The problem is that the dialog does not exist in the DOM (despite your calling $(document).append(). You cannot append a div as a child of the document itself). Instead, append the dialog to the body and hide it.
$dlg = $('<div></div>').hide();
$('body').append($dlg);
Works here: http://jsfiddle.net/yL6ds/4/
Is this possible?
Very much in need of the window.scrollTo() function, but it seems that sites like Facebook and others have removed them (or at least removed the references).
They have not removed them. It does matter when you call them though.
Since most content if FB is brought in the page by ajax, if you call the scroll before the content is fetched, there is nowhere to scroll..
If you open firebug (or whatever javascript console you use) and issue a window.scrollTo(0,1000) while a page is displayed, it will scroll just fine. So it is there.
So be more specific about what you are trying to do, so we can see if we can help.
update after comment
For orkut specifically: They have created a wrapper div of the whole content that is 100% width and height. So the window does not have any room to scroll, as all content is isnide the wrapped and the scroll happens there. So the window.scrollTo does nothing (it exists though).
To actually scroll in there you need to find the container div which is the parent of the one with id gwtPanel and use its scrollTop property.
var scrollingNode = document.getElementById('gwtPanel').parentNode;
scrollingNode.scrollTop=500;