In Chrome Devtools, you can break javascript on changing a DOM element's attributes, or on subtree modifications of an element.
I'm working on some legacy code that has some javascript that scrolls to the top of the page under certain situations, and I want to find the JS that does this.
Is there a way, in Devtools, so break on scroll events?
It could be jQuery or Prototype.js or event base JS that does it, and I've searched the codebase for .scrollTop or .animate, and I've found plenty of those, but none that are causing my issue.
I have no additional idea about actually breaking than the ones presented.
But i suspect it is not scrolling that causes the issue, but a '#' in the html.
x
is a very common pattern. when you forget (or something prevents) the "return false", the # (empty anchor) will be navigated to, which causes a scroll to top.
Check if the url has a # at the end after clicking!
You can inject this line of JS using the console to trigger the debugger when the scroll position changes programatically.
window.__defineSetter__("pageYOffset", function(){
debugger;
});
Then, view the call stack to see what triggered it.
If you don't want to activate the debugger, you can print the stack trace istead with the following code:
window.__defineSetter__("pageYOffset", function(){
console.log(new Error().stack);
});
Another option is to replace the windows scroll, scrollTo and scrollBy method with your own.
window.__defineGetter__('scroll', function(){
console.log('window.scroll getter :' + new Error().stack);
return function(x,y){
debugger; //or print stack trace
oldScroll(x,y);
}
});
Repeat for scrollTo and scrollBy.
Related
I have a custom date picker popup that isn't working in IE sometimes. It works in Chrome and Edge fine.
The code looks something like this:
<frameset>
<frame>Buttons for next/prev month/year</frame>
<frame>This is the actual calendar that gets redrawn when the above buttons are used
1 //there's a different anchor tag for each day of the month
</frame>
<frameset>
So here's where it gets kind of weird. We have two networks, call them old and new. Old has probably a lot of undocumented global policy changes and new is probably close to the gov standard. This works on any browser on the old network, but not IE (11) on the new network. It works in Edge though. Additionally, if the top frame buttons are used to pick the next/prev month, or just the "Today" button, then all of the bottom frame anchor links work normally. There are no console errors/warnings, nothing in the network monitor showing a request returned an error code, the clicks just don't register. I put a breakpoint inside customFunction() and it won't break when the links don't work, but it will break if the link will work.
The only other thing that seems odd to me is that the code for the whole popup looks something like:
str = "<frameset><frame name='topFrame' " +
"src='javascript:parent.opener.drawTop'></frame><frame name='bottomFrame' "+
"src='javascript:parent.opener.drawBottom'><frame</frameset>"
document.write(str);
I did look to check and the code that redraws the bottom frame when the prev/next/etc buttons are used is the same function that gets called during the first load.
However, what seems odd about this is that on the first load the DOM inspector shows everything (top frame, bottom frame including all the individual numbers for each day of the month, etc), but the Debugger (F12 tools) doesn't show the code loaded with the document.write(str); line. To be able to see that code and set break points I have to use the prev/next buttons and then an additional .html file shows up in Debugger which has the constructed HTML that matches the DOM.
try this:
1)
1
2)
1
3)
1
4) check your code. Maybe your frame has attribute 'sandbox'. This attribute can block javascript. Example:
<iframe src="URL" sandbox>
Aside from the great suggestions by Nutscracker, I've also had my share of vague problems with document.write and event handlers not attaching in IE. The problem commented on by ConnorsFan could be the cause here, but you could also try:
document.body.innerHTML = '<frameset><frame name="topFrame" ' +
'src="javascript:parent.opener.drawTop"></frame><frame name="bottomFrame" '+
'src="javascript:parent.opener.drawBottom"><frame></frameset>'
You might also want to check this code is actually being called, maybe the real working popup is loaded from somewhere else by the prev/next buttons and this is just some leftover stuff.
If your onclick function returns false the default browser behaviour is cancelled. As such:
<a href='http://www.google.com' onclick='return check()'>check</a>
<script type='text/javascript'>
function check()
{
return false;
}
This means that you can set your JavaScript function as an onclick event, and just have the anchor tag linking back to the page you are on - as it won't redirect you when you click it but needs a href attribute.
I use JQwidgets ,, I use to print data onclick print-button
as code :
$("#print").click(function () {
var gridContent = $("#jqxgrid").jqxGrid('exportdata', 'html');
var newWindow = window.open('', '', 'width=800, height=500'),
document = newWindow.document.open(),
pageContent =
'<!DOCTYPE html>\n' +
'<html>\n' +
'<head>\n' +
'<meta charset="utf-8" />\n' +
'<title>jQWidgets Grid</title>\n' +
'</head>\n' +
'<body>\n' + gridContent + '\n</body>\n</html>';
document.write(pageContent);
document.close();
newWindow.print();
});
When I close printing-widow(not continue printing), I can't use the grid-scroll (on chrome)..
google-chrome Version 34.0.1847.131 m
This worked fine on Firefox and IE..
How to fix the scroll after closing printing-window on chrome
Fiddle-Demo
It looks like you're not the only one with this issue.
I understand that your code is already setup and you want to run with what you have, but unless someone comes up with a hack or Google decided to fix what is clearly a bug, I think you need to re-think how you are approaching this issue.
If chromeless windows were an option, or if the print dialogue were a modal then you could pull this off with the current strategy, but neither of those options are possible in Chrome. Even if you were able to get around this scrolling issue somehow you're still left with a less than desirable UX problem in that if the user hits "cancel" in the print dialogue then they are left with a still open blank window.
Here is a JS fiddle to demonstrate that you need to change your approach: DEMO
You can see from this demonstration that even if we run a completely separate script from within the new window by passing it as plain text in the content object, it still causes the same issue. This means to me that this is a parent/child type of a relationship that is not easily circumvented with JS.
I recommend 2 alternative possible solutions:
Option1:
<input type="button" value="Print" onclick="window.print(); return false;" />
This triggers a full screen print dialogue that can't be closed from the "Windows Close Button." That way you can avoid the issue all together. Then you can use a combination of JS and Print Styles to target and isolate the information you want to print. I know it's more work but I think may be the better cross-platform solution.
This option is more brute force and simplistic in nature (and you have already commented that you know this but I'm leaving it up because it's still an option).
DEMO
Option2:
User clicks on a link/button that opens a new tab/window
In the same function the data from your table gets loaded into a JSON Object
The JSON object is loaded into a print template in the new tab/window
the template initiates the print function
By taking these actions, I think you will have disassociated the JS instance enough that the new tab will not affect the initiating script.
This is a browser bug - you'd have to find some sort of hack to fix it.
Doesn't sound like you want to put the print dialog code elsewhere thus not affecting your scroll bar. That is the obvious solution but it sounds like you can't do that.
Here's what I would do: Wait until someone has triggered the problematic condition, then put an event listener on the scroll event. when it happens... go ahead and reload the page.
Simple, easy, fun.
var needToReload = false;
$("#print").click(function () {
... as you have
needToReload = navigator.userAgent.toLowerCase().indexOf('chrome') > -1;
}
$('#contentjqxgrid').scroll(function () {
if (needToReload) {
window.location.reload();
}
});
$("#jqxscrollbar").jqxScrollBar({
width: 5,
height:180,
theme:'energyblue',
vertical:true
});
$("#jqxscrollbar1").jqxScrollBar({
width: 300,
height:5,
theme:'energyblue'
});
Look at jsfiddle: http://jsfiddle.net/8PtUX/6/
I came across this in some JS code I was working on:
if ( typeof( e.isTrigger ) == 'undefined' ) {
// do some stuff
}
This seems to be part of jQuery. As far as I can see it tells you if an event originated with the user or automatically.
Is this right? And given that it's not documented, is there a way of finding such things out without going behind the curtain of the jQuery API?
In jQuery 1.7.2 (unminified) line 3148 contains event.isTrigger = true; nested within the trigger function. So yes, you are correct - this is only flagged when you use .trigger() and is used internally to determine how to handle events.
If you look at jQuery github project, inside trigger.js file line 49 (link here) you can find how isTrigger gets calculated.
If you add a trigger in your JavaScript and debug through, You can see how the breakpoint reaches this codeline (checked in jQuery-2.1.3.js for this SO question)
Modern browsers fight against popup windows opened by automated scripts, not real users clicks. If you don't mind promptly opening and closing a window for a real user click and showing a blocked popup window warning for an automated click then you may use this way:
button.onclick = (ev) => {
// Window will be shortly shown and closed for a real user click.
// For automated clicks a blocked popup warning will be shown.
const w = window.open();
if (w) {
w.close();
console.log('Real user clicked the button.');
return;
}
console.log('Automated click detected.');
};
If you open a window like:
window.open ("url","winName","location=0,width=300,height=214");
If winName is already open it just changes the URL in the window. This is ok but if that window is behind the current window most users won't realize this and think that it is just not opening.
Is there any way that if the window is already open, it brings it to the front?
Update: This hasn't worked since Chrome (21+). The workaround is to close/reopen.
The window.open() method returns an object that represents the new window. You just need to window.focus() it:
var w = window.open ("url","winName","location=0,width=300,height=214");
w.focus();
Or simply:
window.open("url","winName","location=0,width=300,height=214").focus();
The various answers suggesting using any form of .focus() are likely not going to work in all browsers.
This used to work back in the day but not any more, mainly due to browsers working to actively stop shady ad networks from pushing their popup ads to the foreground.
In Mozilla Firefox in particular (depending on your version) there is a configuration setting that is turned on by default that stops other windows (e.g. popups) from focusing themselves.
You can find this setting in the about:config page (tread carefully!)
dom.disable_window_flip: true
If I recall correctly this setting used to be called something like ~"allow_raise_or_lower_windows*
Other browsers may implement something similar, but quite simply if 1 of the major browsers blocks the use of .focus() by default then there's not much use in attempting to call it.
As a result, the only solution I've seen that works is to see if the window exists, and is not already closed... and if so close it, then load the window you want.
function closePopupIfOpen(popupName){
if(typeof(window[popupName]) != 'undefined' && !window[popupName].closed){
window[popupName].close();
}
}
when opening your popup if there's a chance it is already open (and burried behind other windows) then you can call this function before you attempt to open your popup.
closePopupIfOpen('fooWin');
var fooWin = window.open('someURL', 'foo', '...features...');
The drawback of course is that if there was anything "important" (e.g. a form partially filled in) in that window it will be lost.
Update: This hasn't worked since Chrome (21+). The workaround is to close/reopen.
Be careful, because when you open a new window, the opener window might still have some code to be executed, maybe some of this code gives it the focus. You would see how your new window opens in the front and suddenly goes to the back, so, it is a great idea in these cases, to set a timeout in order to give the focus to the new window a bit later on, when all the javascript in the opener window is executed, you can do it this way:
setTimeout(function(){window.focus();},1000);
Being 1000 the amount of miliseconds to wait, and window the name of the opened window.
You could also use this code in the opened window in the body onload for example.
I fixed this by adding
onclick="myWin = window.open('','winName','location=0,width=300,height=214'); myWin.focus()"
to the html element(button) and then change the URL via JS.
window.focus() applied to the window in question should do the trick.
You can use jQuery :
myPopup = window.open(url, "Title","menubar=no, status=no, scrollbars=no, menubar=no, width=800, height=800");
$(myPopup).focus();
Closing the window first, does the trick for me:
window.open('', 'mypopup').close();
setTimeout(function() {
window.open('', 'mypopup').focus();
}, 500);
I had the same problem, have spent a lot of time to find a solution, finally it works by this:
var singleWindow;
function openNewWindow(){
if(singleWindow){
singleWindow.close();
}
singleWindow = window.open ("url","winName","location=0,width=300,height=214");
}
This close the current window (if exist) and open a new window that will be placed on the top (default behavior)
Hope this help you !
What is the proper way to close an ExtJS tab programmatically?
I need to make this work in IE6; although remove'ing the tab from the TabPanel works, I see an IE warning: This page contains secure and unsecure items... When I click the X on the tab, I do not see this warning. So, clearly something clever is happening when I click the X.
Note: the warning occurs when I use tabPanel.remove(aTab, true) and it does not occur when I use tabPanel.remove(aTab, false). So, the mixed content warning is displayed during the removal and subsequent destruction of the panel.
Does it make sense to simulate the click on a tab?
EDIT
IE is telling me I have mixed SSL content when I don't
Are you removing the tab's element directly, or are you removing the tab component from its container? E.g.:
Ext.fly('tab-id').remove(); // Element API
vs.
myTabPanel.remove('tab-id'); // Panel API
Both should work OK in terms of nuking the tab markup, but removing the element directly may have undesirable consequences. If you are doing the latter (correct), then I'm not sure what the issue might be. I don't have IE 6 handy myself.
This closes a tab by clicking the middle button of your mouse.
var middleClick = $(document).mousedown(function(e) {
if(e.which == 2){
var tabPanel = <%= tabPanel.ClientID %>;
var activeTab = tabPanel.getActiveTab();
if (e.target.textContent == activeTab.title) {
var activeTabIndex = tabPanel.items.findIndex('id', activeTab.id);
tabPanel.remove(activeTabIndex);
}
}
return true;
});
Hope it helps!! =)