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.
Related
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.
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/
As the title says "Google Chrome opens window.open(someurl) just fine...but page/window with clicked link also opens someurl.com.
When I click the "Click here" link with the onclick="shpop..." call attached, my pop up opens /facebook_login.php' correctly...BUT...at the same time, the original window opens /facebook_login.php too!
This happens in Chrome and IE, but FF is fine and doing just what i want..
I have this link:
Click here
I know I could remove the href="/facebook_login.php" and replace with href="#" .. but I need the link to work if js is disabled.
I have this js code imported in my tag:
function shpop(u,t,w,v)
{
var text = encodeURI(t);
var uri = encodeURI(u);
var h = document.location.href;
h = encodeURI(h);
var wwidth='600'; /*popup window width*/
var wheight='300'; /*popup window height*/
if(v=='' || undefined==v)v=document.domain; /*popup name/title */
switch(w){
case 'loginfb':
var url = '/facebook_login.php';
wwidth='980';
wheight='600';
break;
}
window.open(url,v,'width='+wwidth+',height='+wheight);
return false
}
Any ideas?
what is with returning false, and having false in the onclick?
This
onclick="shpop('','','loginfb','');return false"
Just needs to be
onclick="return shpop('','','loginfb','');"
If the onclick returns any error, the link will still open up. Do you see any errors in the JavaScript console? I wonder if the browsers are freaking out about any . in the window name from using document.domain. Try giving it a name.
onclick="return shpop('','','loginfb','foobar');"
According to the latest browser statistics - well last time it was measured anyway (2008) only 5% of users had Javascript disabled. Nowadays it's likely to be less. Consider that all browsers have it enabled by default. Therefore it's generally only advanced users that for whatever reason choose to disable javascript, and will therefore understand that there's a good chance any website they visit won't work as expected - Facebook, Google, Amazon - everyone uses javascript these days. It's perfectly acceptable to assume the user is using it, with one overall <noscript> version at the start of your page for those users if you really really want to cover all your bases :)
Here is the simplest solution:
<a href="/facebook_login.php"
target="FBpopup"
onclick="window.open('about:blank','FBpopup','width=980,height=600')">
Click here
</a>
You don't need return false because you actually want the link to execute.
The trick is to use the same window name in both the window.open and in the link target.
window.open will create the popup, then your login page will run in that popup.
If popups are blocked or Javascript is disabled, your login page will run in a new tab.
A while back I created a lightbox plugin using jQuery that would load a url specified in a link into a lightbox. The code is really simple:
$('.readmore').each(function(i){
$(this).popup();
});
and the link would look like this:
<a class='readmore' href='view-details.php?Id=11'>TJ Kirchner</a>
The plugin could also accept arguments for width, height, a different url, and more data to pass through.
The problem I'm facing right now is printing the lightbox. I set it up so that the lightbox has a print button at the top of the box. That link would open up a new window and print that window. This is all being controlled by the lightbox plugin. Here's what that code looks like:
$('.printBtn').bind('click',function() {
var url = options.url + ( ( options.url.indexOf('?') < 0 && options.data != "" ) ? '?' : '&' ) + options.data;
var thePopup = window.open( url, "Member Listing", "menubar=0,location=0,height=700,width=700" );
thePopup.print();
});
The problem is the script doesn't seem to be waiting until the window loads. It wants to print the moment the window appears. As a result, if I click "cancel" to the print dialog box, it'll popup again and again until the window loads. The first time I tried printing I got a blank page. That might be because the window didn't finish load.
I need to find a way to alter the previous code block to wait until the window loads and then print. I feel like there should be an easy way to do this, but I haven't found it yet. Either that, or I need to find a better way to open a popup window and print from the lightbox script in the parent window, without alternating the webpage code in the popup window.
You should put the print function in your view-details.php file and call it once the file is loaded, by either using
<body onload="window.print()">
or
$(document).ready(function () {
window.print();
});
Got it! I found an idea here
http://www.mail-archive.com/discuss#jquery.com/msg18410.html
In this example, they loaded a blank popup window into an object, cloned the contents of the element to be displayed, and appended it to the body of the object. Since I already knew what the contents of view-details (or any page I load in the lightbox), I just had to clone that content instead and load it into an object. Then, I just needed to print that object. The final outcome looks like this:
$('.printBtn').bind('click',function() {
var thePopup = window.open( '', "Customer Listing", "menubar=0,location=0,height=700,width=700" );
$('#popup-content').clone().appendTo( thePopup.document.body );
thePopup.print();
});
I had one small drawback in that the style sheet I was using in view-details.php was using a relative link. I had to change it to an absolute link. The reason being that the window didn't have a URL associated with it, so it had no relative position to draw on.
Works in Firefox. I need to test it in some other major browsers too.
I don't know how well this solution works when you're dealing with images, videos, or other process intensive solutions. Although, it works pretty well in my case, since I'm just loading tables and text values.
Thanks for the input! You gave me some ideas of how to get around this.
Are you sure you can't alter the HTML in the popup window?
If you can, add a <script> tag at the end of the popup's HTML, and call window.print() inside it. Then it won't be called until the HTML has loaded.
I'm having some issues with a jQuery AJAX call. My code works fine when I request a page with no javascript in it, but when I have script tags in my code, things start to get weird.
It seems that any script tags referencing external URLs cause the browser to redirect. In firefox, the page goes blank. In safari, the page clears and loads with the content of the AJAX response. In both browsers, the URL doesn't change.
To be specific about my problem; I have a tab control in which I'm trying to embed the walkscore widget. Since it's pretty heavy on the client side, I only want to actually load it once the user clicks the tab it's in. The walkscore AJAX page looks like this:
<script type="text/javascript">
var ws_address = "1 Market St, San Francisco";
var ws_width = "500";
</script>
<script type="text/javascript" src="http://www.walkscore.com/tile/show-tile.php?wsid=MY_WSID">
</script>
Is there some restriction on script tags referencing external sites on AJAX calls? Is there any nice way around this?
-- Edit --
OK I've been playing with it for a bit and have narrowed down the problem a little. Let me try give a better explanation at the same time:
I have two files, index.html and walkscore.html
index.html
function widget() {
var widget = $('#walkscore');
$.get('/walkscore.html', function(data) {
$('#loading').slideUp(function() {
widget.html(data);
loaded[name] = true;
widget.slideDown();
});
});
}
walkscore.html - as shown in the top code block
In index.html, I have a link that calls the widget function. Whenever I click this link, the whole page is replaced by the output of the js file. It happens regardless of the domain the js file is from. It only seems to happen with js files that have document.write in them. It behaves in exactly the same way when I use the $.getScript function, even when it's in index.html
-- Edit --
It seems it has everything to do with the document.write. I made a copy of the walkscore javascript and replaced all occurrences of document.write with jquery.html, and it seems to work properly. I'm (obviously) a js noob. Is this the expected behavior of document.write? How come it doesn't do it when I include the script on a page load?
Load script separately from html content, you can use $.getScript( ).
It has to do with the document.write in the response.. I was able to fix this in Firefox by doing this:
<script type="text/javascript">
// save default document.write function so we can set it back
var write_func_holder = document.write;
// redefine document.write to output text target div
document.write = function(text) {
$('#ad_container').html($('#ad_container').html() + text);
}
</script>
<script language="JavaScript" type="text/javascript" src="javascriptfile">
</script>
<script type="text/javascript">
// reset document.write function
document.write = write_func_holder;
</script>
I'm still getting an issue in Safari where the browser refreshes to a blank page with just the content of the document.write and IE6, IE7 doesn't do anything at all. Firefox works though.
I hope this helps someone figure out what wrong and they in turn can fix the IE6/7 and Safari issues
It happens because of the document.write call. Here's some info on what's going on:
Writing After A Page Has Been Loaded
If document.write() is invoked after a page has finished loading, the entire static (non-script generated) content of a page will be replaced with the write method's parameter. This scenario is most often played out when the write method is invoked from an event handler - whether the method is in a function called by the event handler or alone inside the handler - because event handlers are triggered after a page has finished loading. This is important to know because static content replacement is not always the desired result. Another common scenario for content overwite has to do with writing content to a new window. In this case, the overwrite of blank page is the goal.
(source)
The solution I went with was to eliminate the document.write commands, and replace the content of a div instead. If you're loading an external script, and have no control over it, you can replace the document.write function with your own. It's discussed here:
http://www.webxpertz.net/forums/showthread.php?threadid=11658
Hope that helps someone out there!
Replacing document.write is the way to go. This is shameless self promotion, but if you have a non-trivial case, writeCapture.js handles all the edge cases.
I would first check the response of that script source, maybe something in that causes the unwanted behavior.
I am experiencing the EXACT same behaviour and spent some frustrating hours last night trying to figure out what the problem was and searching for answers to no avail. I'm surprised this is mentioned anywhere in the jquery docs as it seems like a plausible problem not some crazy never-to-be-encountered bug.
Anyway, here's my story in case anyone searches for something related.
I have a jquery enabled page that loads some content into a div using $.ajax(), it all works perfectly. What I needed to do was include one of those twitter retweet buttons that shows a count and enables you to tweet about the content on the page. To do this a simple piece of javascript from them should be included on the page.
<script type="text/javascript" src="http://www.retweet.com/static/retweets.js"></script>
So in theory, that script tag should be returned in the ajax call and jquery should execute it and include the result of it, as I specified the data type as html in the $.ajax() call.
The external script on closer inspection does:
if(!url)
{
var url=window.location.href;
}
if(!size)
var size="big";
var height="75";
var width="54"
if(size=="small")
{
height="22";
width="120";
}
if(!username)
var username="none";
url=url.replace("?", "*");
var src="http://www.retweet.com/widget/button/"+size+"/"+username+"/"+url;
document.write('<iframe src="'+src+'" height="'+height+'" width="'+width+'" frameborder="0" scrolling="no"></iframe>');
Which obviously bombs out on the document.write.
Tonight i'll try the methods in this post and see if they work, thanks for the info.