I'm trying to implement a notification functionality which would change the browser tab text with the number of notifications. I searched on the internet and found that I should change the title which would change the browser tab text too . But it doesn't seem to work. Here is what I tried:
var nbNotifications = 0;
$().ready(function() {
var docOriginalTitle = "Tab does not change on notification";
debugger;
document.title = docOriginalTitle;
$('#test').click(function() {
nbNotifications += 1;
document.title = "(" + nbNotifications + ") " + docOriginalTitle;
alert(document.title);
});
});
JSFiddle can be found here
Perhaps, it's not true that the document title changes the browser tab title? Or maybe it doesn't work with JSFiddle?
Could you put me on the good track?
Edit
I'm trying to change the browser tab text in JSFiddle. Is there a way to cheat JSFiddle and render this behaviour?
I think this technique works just fine. I think the problem is that jsFiddle runs your page in an iframe, which does not control the browser tab title.
If I enter document.title = 'Here's my new Title'; in the browser console, the text in the browser tab does update.
How else have you tested this?
document.title is the way to go, but it won't work in jsFiddle. It should work fine in a "real" page.
Try typing javascript:alert(document.title = "My new title"); into your browser - you should see the tab text update.
Edit:
I don't think you can do this in jsfiddle unless they allow for it somehow. If you try to "escape" your window and change properties on theirs (i.e. parent.document.title = "xxx"; you get a security exception:
Uncaught SecurityError: Blocked a frame with origin
"http://fiddle.jshell.net" from accessing a frame with origin
"http://jsfiddle.net". Protocols, domains, and ports must match.
Related
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 have a link which when clicked redirects the user to the same page except with additional parameters:
<a id="lnkExportToPDF" href="javascript:void(0)">Export</a>
$('#lnkExportToPDF').click(function (e) {
e.preventDefault();
window.location.href = path + 'users/export/' + parm1 + '/' + parm2;
});
On the server side I handle it by checking for "export" in the request path, and if it's found I write a PDF file to the response:
System.Web.HttpResponse response = System.Web.HttpContext.Current.Response;
response.Clear();
response.AddHeader("Content-Type", "application/pdf");
response.AddHeader("Content-Disposition", String.Format("attachment; filename=" + filename + ".pdf; size={0}", buffer.Length.ToString()));
response.BinaryWrite(buffer);
response.End();
Everything works and the user can download the file, but any additional actions by the user that uses the loader.gif which is on the page shows an unanimated loader.
What could be causing this to happen? Is there any way to refresh/reload the page/javascript after the response is complete?
edit: I've found a useful JS tool here: http://fgnass.github.io/spin.js/ but I'd prefer not to use it unless absolutely necessary
edit2: I also tried using a generic handler (.ashx) to handle the request (ie. changing the href to point to the handler), but as soon as the page redirects and the file is written, same thing happens
edit3: The problem is only happening in Firefox so far. I've tried Chrome and IE and the gif stays animated in those browsers. (latest versions of each)
edit4: If I use an iframe with the src as the image it solves the issue, but it's very hacky and the style of it looks different across all browsers with regards to centering/padding/margins.
edit5: Yeah. If I inspect the frozen gif with firebug it magically unfreezes itself.
I managed to recreate the problem in firefox and I really can't find a way to "unfreeze" the gif. When I added a completely different file after a download and that too was frozen I gave up with that approach.
What I did instead was to test different ways to trigger the download. I found no window.location solutions that worked, what did work though was this:
window.open(path + 'users/export/' + parm1 + '/' + parm2);
window.open opens a new tab and downloads the file through that instead of the current tab as window.location does. It will return to the current tab as soon as the download starts.
Edit
You could also use a hidden iframe:
var iframe = document.getElementById('iframe');
iframe.src = path + 'users/export/' + parm1 + '/' + parm2;
I confirm that I have the same behavior with firefox, and the first that come to my mind is to use SetTimeOut but still the same behavior, so on firefox for some reason, this window.location.href is also call the "Stop" on browser, that this cause the gif animation to stop.
So what I found and you can solve your issue, that this is not happends on simple links.
And if you change your code you can archive the same effect with a link.
So change this
$('#lnkExportToPDF').click(function (e) {
e.preventDefault();
window.location.href = "page.aspx";
});
to something like this
$('#lnkExportToPDF').attr("href", "page.aspx");
and you have the same results, and gif will still moving.
Here is the fiddle test.
On the test I add to move to paypal, because is slow moving and you can see the animation stop or not, also pp not let show on iframe, so on example you stay on example and not load the page.
When you click on this example, the issue is appears only on firefox !
http://jsfiddle.net/hn7S9/4/
One other issue that I think is that if you need to make your parametres to the next page on click, you probably need to redesign that and fix them before your click.
This is possible because for sure is not depends on the last click on the dynamic create link. So make the link with their parametres before the click.
You could try an asynchronous approach on the click to allow the browser to parse the event queue after the click has initiated:
$('#lnkExportToPDF').click(function (e) {
e.preventDefault();
setTimout(function() {
window.location.href = path + 'users/export/' + parm1 + '/' + parm2;
}, 20);
});
How about allowing the link to actually fire, but opening it in a new tab?
That shouldn't interrupt anything about the gif, and is semantically fine, other than I guess it would leave a tab open. You could get rid of the content-disposition, and allow the browser /user to decide what to do with it though.
<a id="lnkExportToPDF" target="_blank">Export</a>
$('#lnkExportToPDF').click(function (e) {
$(this).attr("href", path + 'users/export/' + parm1 + '/' + parm2);
});
Instead of setting the window.location.href, you can use a form with method="get" and submit it. This form could either be coded into your HTML or created dynamically. See this Answer:
https://stackoverflow.com/a/21742326/1614903
Here's my solution. It's faster and easier than any fix or workaround I've found. Just open the problem page in Chrome. Chrome has it's own problems, but this isn't one of them. Whenever I encounter a page full of gifs that causes Firefox to freeze, I just copy the URL, close the tab, open Chrome, and paste in the URL. I works every time! :o)
I've been working on a Frame busting buster (what's in a name, hehe), which kept my users on my page and open a new window with the target URL. I'm using a Lightbox script to display iframes, this is what I'm doing:
1) Added an event for all .lightbox clicks, f.e:
$('.lightbox').live("click", function(e) {
e.preventDefault();
$('#redirectURL').val($(this).attr('href'));
$(this).lightbox();
}
2) Added a frame busting buster:
<script type="text/javascript">
var prevent_bust = 0
window.onbeforeunload = function() { prevent_bust++ }
setInterval(function() {
if (prevent_bust > 0) {
prevent_bust -= 2
window.top.location = 'http://server-which-responds-with-204.com'
}
}, 1)
</script>
3) Modified the frame busting buster code to fit my needs, which are:
detect if an iframe wants to change the window.top.location
if so, prevent this from happening using the 204 server respond
open a new page: window.open( $('#redirectURL', '_blank' );
close lightbox: $('.jquery-lightbox-button-close').click();
So far, this is what I've come up with:
var prevent_bust = 0
window.onbeforeunload = function() { prevent_bust++ }
setInterval(function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
redirectURL = $('#redirectURL').val();
if(redirectURL != "") {
window.top.location = 'http://www.****.com/ajax/nocontent.php';
window.open(redirectURL, "_blank");
$('.jquery-lightbox-button-close').click();
$('#redirectURL').val('');
} else {
window.top.location = 'http://www.****.com/ajax/nocontent.php';
}
}
}, 1);
// EDIT: Before I forget, 'nocontent.php' is a file that returns a 204 header
For Firefox it acts as I programmed it, if there's a change detected in the window.top.location it opens a new frame/page and prevents the iframe from reloading the top location and to round it up, it closes the jQuery lightbox.
Safari/Chrome act similar, they open a new browser screen (not sure if theres an option to say target="_newtab" or something?). Only bad thing is they do not really display a message of the popup is blocked, but I can work around that by displaying a popup balloon on my website with a link to the page.
Internet Explorer is, what a shocker, the only black sheep left.. IE does not open a new popup, nor blocks the window.top.location reset by the iFrame and simply continues refreshing the complete page to the '#targetURL'. It does the same with the default busting code.. so it's not because of some of my edits.
Anyone who is able to spot a mistake in my code?
Also, I would need a little modification that sees if the request has been made by an iframe or by the user itself, because now there is really NO option for a user to leave my page by changing the address in the toolbar or by clicking a link, which is not really needed LOL.
Thanks in advance.
PENDO, I tried to simulate the whole process you described, ligthbox-jquery, javascript their own codes and controls opening pages via lightbox. I could not simulate at all, and as time is running out I'm sending a suggestion to broaden the range of possibilities and solutions.
I suggest replacing the redirect page:
...
redirectUrl = $ ('# redirectUrl'). val ();
...
window.top.location = 'http://www .****. with / ajax / nocontent.php';
window.open (redirectUrl, "_blank");
Replaced with a DIV container that simulates a page, using ajax calls and taking the content and overwritten the contents of the DIV.
...
$.post(redirectoURL /* or desired URL */, function(data) {
$('DIV.simulateContent').html(data);
});
...
or
...
$('DIV.simulateContent').load(redirectoURL);
...
This approach also avoids the problem of preventing the user from even leaving your page using the address bar (as you yourself mentioned).
Sorry, let me give you a complete solution, but time prevented me.
PENDO, a little more work on alternatives to the problem, I found a customizable jQuery lightbox plugin for working with custom windows yet (iframe, html, inline ajax etc.). Maybe it will help. The following link:
http://jacklmoore.com/colorbox/
If you don't need javascript running in your iframe in IE, you can set the iframe security attribute :
<iframe security="restricted" src="http://domain.com" />
http://msdn.microsoft.com/en-us/library/ms534622(v=VS.85).aspx
For example, there is a "Link" called go to view at the bottom of the my page, which is redirecting to http://localhost/test.php.
If we use $_SERVER['HTTP_REFERER'] in test.php page it will display the url of the page from which link was clicked.
The problem is this: my URL can be seen at the target page. This needs to be avoided. How can i do this using javascript?
When JavaScript gets to it, it is too late. Plus JavaScript can not do it.
There is no cross-browser solution. For example this code works in Chrome, but not in FF:
classic html link<br/>
js trickery
<script>
function goto(url) {
var frame = document.createElement("iframe");
frame.style.display = "none";
document.body.appendChild(frame);
frame.contentWindow.location.href="javascript:top.location.href = '" + url + "';";
}
</script>
There are third party solutions. You can find any number of them by searching "referer hide" or "refer mask" with you favorite search engine. - Some of them look sady, so try to find a trustworty one.
On the other hand. This is part of Internet culture. Referers can be used for valuable statistics for example. And if your website is in a crawler's index, they can find the link anyway.
Check http://www.referhush.com/
As sentence on this site says :"Webmasters can use this tool to prevent their site from appearing in the server logs of referred pages as referrer."
i have Problem with opening popups in javascript i have this function to open my popups in IE6 and IE7:
function open_window(Location,w,h) //opens new window
{
var win = "width="+w+",height="+h+",menubar=no,location=no,resizable,scrollbars,top=500,left=500";
alert(win) ;
window.open(Location,'newWin',win).focus();
}
it's working . i mean my new window opens but an error occurs. The Error Message is :
'window.open(...)' is null is not an object.
do you want to countinue running script on this page ?
then i have button in onclick event it's will call a function to close current window an refresh the opener function is
function refreshParent(location)
{
window.opener.location.href = location ;
window.close();
}
it's also gives me error : window.opener.location is null or not an object but i'm sure i'm passing correct parameters
i call it like this :
for second part :
<input type="button" name="pay" value="test" onclick="refreshParent('index.php?module=payment&task=default')" >
for first part :
<a onclick="javascript:open_window('?module=cart&task=add&id=<?=$res[xproductid]?>&popup=on','500' , '500')" style="cursor:pointer" id="addtocard"> <img src="../images/new_theme/buy_book.gif" width="123" border="0"/> </a>
it's really confuse me . Please Help ;)
When popup windows opened using window.open are blocked by a popup blocker, a feature of pretty much any modern browser these days, the return value of window.open() is not a window object, but null.
In order to circumvent these issues you would need to test the value returned by window.open() before attempting to invoke any methods on it.
Below is a piece of code to demonstrate how to go around this problem:
function open_window(Location,w,h) //opens new window
{
var options = "width=" + w + ",height=" + h;
options += ",menubar=no,location=no,resizable,scrollbars,top=500,left=500";
var newwin = window.open(Location,'newWin',options);
if (newwin == null)
{
// The popup got blocked, notify the user
return false;
}
newwin.focus();
}
In general, popup windows should be used only as a last resort or in controlled environments (internal company website, etc). Popup blockers tend to behave in very inconsistent ways and there may be more than a single popup blocker installed in a given browser so instructing the user on how to allow popups for a given website is not necessarily a solution. Example: IE7 + Google toolbar = two popup blockers.
If I may suggest, perhaps you should consider using something like this:
http://jqueryui.com/demos/dialog/
The advantages are numerous:
Skinnable, so you can create a more consistent look to match your website.
No popup blockers.
Good API and documentation that is consistent across most, if not all, major browsers.
If you still require that the newly opened "window" contain an external URL, you could use an IFRAME inside the opened dialog window.
Hope this helps,
Lior.
Works perfectly fine for me. Tested in IE6/7/8.
Of course I couldn't test it with your URLs so I replaced these with simple filenames. I'd suggest you try it also with simple filenames and see if it also fails then.
Beside that...
You don't need to add "javascript:" at the beginning of onclick attribute value.
It would also be good if you added a href="..." attribute to the link with the same URL that you give to open_window. Then it would become a real link and you wouldn't have to add cursor:pointer to it. For example:
<a href="?module=cart&task=add&id=<?=$res[xproductid]?>&popup=on"
onclick="open_window(this.href, '500' , '500'); return false;"> ...
Here is a way to have your cake and eat it too
I have not tested it on all browsers but it should really work
function open_window(url,target,w,h) { //opens new window
var parms = "width="+w+",height="+h+",menubar=no,location=no,resizable,scrollbars,top=500,left=500";
var win = window.open(url,target,parms);
if (win) {
win.focus();
return false; // cancel the onClick
}
return true; // make the link perform as normal
}
Using the link
<a href="?module=cart&task=add&id=<?=$res[xproductid]?>&popup=on"
target="newWin"
onclick="return open_window(this.href,this.target,500,500)"
id="addtocard"><img src="../images/new_theme/buy_book.gif" width="123" border="0"/></a>
which even saves you the silly cursor thing since it is an actual link which works even when JS is turned off