We have a legitimate popup on our site which is when the user hits the live chat button a window appears with the chat inside. This worked no problem. We recently switched to a new host, and now the popup is blocked. Are popup blockers somehow aware of the host IP (which will have changed)? If so, I can only assume this previous IP was "bad" and hence it got blocked, is there a way to amend this (this was using Chrome).
Original JS Code
<a href="contact-us" class="button green icon" onclick='lpButtonCTTUrl = 'http://server.iad.liveperson.net/hc/12345678/?cmd=file&file=visitorWantsToChat&site=12345678&referrer='+escape(document.location); lpButtonCTTUrl = (typeof(lpAppendVisitorCookies) != 'undefined' ? lpAppendVisitorCookies(lpButtonCTTUrl) : lpButtonCTTUrl); lpButtonCTTUrl = ((typeof(lpMTag)!='undefined' && typeof(lpMTag.addFirstPartyCookies)!='undefined')?lpMTag.addFirstPartyCookies(lpButtonCTTUrl):lpButtonCTTUrl);window.open(lpButtonCTTUrl,'chat12345678','width=475,height=400,resizable=yes');return false;'>ChatNow</a>
Readable version of the onclick part:
lpButtonCTTUrl = "http://server.iad.liveperson.net/hc/12345678/?cmd=file&file=visitorWantsToChat&site=12345678&referrer=" + escape(document.location);
lpButtonCTTUrl = (typeof(lpAppendVisitorCookies) != "undefined" ? lpAppendVisitorCookies(lpButtonCTTUrl) : lpButtonCTTUrl);
lpButtonCTTUrl = ((typeof(lpMTag)!="undefined" && typeof(lpMTag.addFirstPartyCookies)!="undefined")?lpMTag.addFirstPartyCookies(lpButtonCTTUrl):lpButtonCTTUrl);
window.open(lpButtonCTTUrl,"chat12345678","width=475,height=400,resizable=yes");
return false;
Related
I would like to port an existing fully functional Chrome extension to Firefox, everything seems to work except the confirm() function behavior.
When the user clicks a specific button in the popup.html page, he is asked to confirm the action.
Chrome successfully prompts the dialog, I then get a Boolean back as soon as "ok" or "cancel" button is clicked, code related to the boolean returned is executed.
Firefox behavior feels buggy on the other hand. The confirm dialog prompts too but the extension popup is instantly dismissed, preventing further code in the click event handler to execute.
manifest.json : …, "default_popup": "popup.html", …
popup.html :
…
<script src="js/popup.js"></script>
</body>
popup.js :
removeButton.addEventListener('click', function () {
// Firefox: calling confirm() closes the popup.html page ...
// ... terminating event handler code
if (confirm("Please confirm you wish to remove this item.")) {
// …
}
});
Is there something to do about it or should I stop using confirm() and find a workaround ?
EDIT - Workaround solution
As a workaround, I set a 3 seconds countdown when the button is clicked and change its caption every second. Before time is up, if the user click again, the final action gets cancelled, otherwise final action is performed.
let log = document.querySelector('p')
,resetInterval = null
;
document.getElementById('resetbtn').addEventListener('click', function(e) {
if (!resetInterval) {
// Create a countdown and delete data when time is up.
e.target.content = e.target.innerHTML;
resetInterval = setInterval( function() {
var counter = +(e.target.innerHTML.trim().match(/\d+/)||[4])[0];
if (counter == 1) {
// Sending command to bacground page
// chrome.runtime.sendMessage({command:'remove'}, function (){
e.target.innerHTML = e.target.content;
resetInterval && clearInterval(resetInterval);
resetInterval = null;
log.innerHTML = 'Perform action…';
// });
} else e.target.innerHTML = 'Reset in '+(counter-1)+'s';
}, 1000);
log.innerHTML = '';
} else {
resetInterval && clearInterval(resetInterval);
e.target.innerHTML = e.target.content;
resetInterval = null;
log.innerHTML = 'Action aborted';
}
});
<button type="button" id="resetbtn">Reset</button>
<p></p>
Popout windows are designed to be dismissed when you move focus to another window. You can’t use dialogs (new windows) from the popout as they’re moving focus and thus dismissing the popout.
I am using this article here to have two domains names point to the same Joomla install, with one having a different home page.
http://docs.joomla.org/Multiple_Domains_and_Web_Sites_in_a_single_Joomla!_installation
(option 2)
The sites open okay, and the second domain even goes to the correct landing page. The issue is that when on the second domain, all menu links open in a new window(they are relative links, but in the html it is adding "target=_blank") and i am not sure why, or how to stop it.
All the menu links properly open in the parent window when on the primary domain.
here are the two live links:
http://www.hustoninsurance.com/
http://tiffinhealthexchange.com/
Thanks in advance.
Running Joomla 3.0
I looked at the page source of tiffinhealth, and there is a function specialtrack() which is adding the target="_blank"
var specialtrack = new (function() {
[...]
var initialize = function() {
var links = document.links;
for (var i = 0, l = links.length; i < l; i++) {
var match = links[i].pathname.match(whitelist);
var match_links = links[i].href.match(domain);
var match_void = links[i].href.match('javascript:void');
if (typeof match_void == 'undefined' || match_void == null) {
if (typeof match !== 'undefined' && match !== null) {
links[i].addEventListener('click',trackpush_downloads,false);
links[i].setAttribute('target', '_blank');
}else if (typeof match_links == 'undefined' || match_links == null) {
links[i].addEventListener('click',trackpush_links,false);
links[i].setAttribute('target', '_blank');
}
}
}
};
The line links[i].setAttribute('target', '_blank'); is the one to blame for adding the target="_blank"; you should investigate with the developer or try to use an alternative solution to serve your purpose; maybe you could also avoid using two tracking on the same page.
Also, in your source you have plenty of absolute urls including the domain name: make sure this is consistent across the two domains otherwise page cache will eventually contain inconsistencies:
<a href="http://www.hustoninsurance.com/images/Showcases/Locations/99 Ashwood Rd/Group.png">
<img src="http://tiffinhealthexchange.com/images/Showcases/Locations/99 Ashwood Rd/Group.png" alt="Group.png"/></a>
I have an application that uses a combination of the onhashchange event (for new browsers) and the hashchange plugin by Ben Alman (for old browsers) to track the history while making ajax calls or actions. Works like a charm in all browsers, back and forward buttons let the user navigate the actions that get recorded by changing the hash. So far so good. Now our page will be hosted in an iframe on a clients page in a diff domain(cross domain). Chrome kind of works but if you put to many changes in the history it stops working at some point (we can live with that). IE dosen't work at all. When I navigate our application by clicking on links and updating the hash new history items get created in the parent page but when I hit the back button the hash in the nested page is not updated therefore the hashchange event never fires. Anyone solved this problem before? Many thanks
Initialize the hash change event handling
if ("onhashchange" in window && !($j.browser.msie && $j.browser.version == '7.0')) {
window.onhashchange = function() {
var params = parseHash(location.hash)
if (params.tabId) {
if (getSelectedTabId() == params.tabId) return;
reloadPage(params.tabId);
}
};
}
else {// Plugin for older browsers
$j(window).bind('hashchange', function() {
var params = parseHash(location.hash)
if (params.tabId) {
if (getSelectedTabId() == params.tabId) return;
reloadPage(params.tabId);
}
});
}
I have protocol (like http) with scheme managed with 3rd party App registered in Mac OS X.
I.e, x-someapp://someaction or something like that.
How can I open this URL with Google Chrome?
By default, Chrome starts searching in Google engine instead launching App and passing URL handling to it...
Safari launches some registered App. And it is right thing.
Firefox and Opera asks what to do... and I can launch App also.
But Chrome... Doesn't ask.
I even tried to write some HTML page with JavaScript inside to send XHttpRequest:
function _httpExecuteCallback()
{
if (httpRequestCallbackFunction != null) {
if (httpRequest.readyState == 4) {
if (httpRequest.status == 200) {
httpRequestCallbackFunction();
httpRequestCallbackFunction = null;
}
}
}
}
function _httpGet(url, callbackFunction)
{
httpRequest = false;
httpRequestCallbackFunction = callbackFunction;
httpRequest = new XMLHttpRequest();
httpRequest.onreadystatechange = _httpExecuteCallback;
httpRequest.open('GET', url, true);
httpRequest.send(null);
}
_httpGet('x-someapp://test',function(){})
No results also...
The current accepted solution has a problem with Chrome for SSL https. Watching the console log, Chrome blocks the request because it thinks the custom url protocol is not secure:
[blocked] The page at reports blah blah ran insecure content from customproto//blah blah
Here is a solution (this took me a few days to research):
<input type='button' value='Test Custom Url' onclick='exec()'>
<script>
function submitRequest(buttonId) {
var d = (window.parent)?window.parent.document:window.document
if (d.getElementById(buttonId) == null || d.getElementById(buttonId) == undefined) return;
if (d.getElementById(buttonId).dispatchEvent) {
var e = d.createEvent("MouseEvents");
e.initEvent("click", true, true);
d.getElementById(buttonId).dispatchEvent(e);
}
else {
d.getElementById(buttonId).click();
}
}
function exec(){
var d = (window.parent)?window.parent.document:window.document
var f = d.getElementById('customUrlLink')
if (f ) {f.parentNode.removeChild(f);}
var a = d.createElement('a');
a.href = 'mycustomproto://arg1';
a.innerHTML = "Link"
a.setAttribute('id', 'customUrlLink');
a.setAttribute("style", "display:none; ");
d.body.appendChild(a);
submitRequest("customUrlLink");
}
</script>
This code will not work for IE. I've found using this technique IE limits the argument of the custom protocol to less than 1000 where as using the iFrame technique IE will allow 2083 chars.
The only way to overcome the url limit in javascript is chuck the data and call multiple times. If anyone wants to take a stab at that, please let me know how it goes. I would like to use it.
To handle long urls in the executing app, pass a token into the app and have it go get the data from a url GET.
So for right now I am using one function for Chrome/FF and another function for IE.
These links helped me develop this solution:
https://superuser.com/questions/655405/custom-protocol-handler-not-working-in-chrome-on-ssl-page
Simulating a click in jQuery/JavaScript on a link
(wish I had known this a few days ago....hope this helps someone)
==================================================
Update: (8hr later)
==================================================
Jake posted a great solution for chrome: https://superuser.com/questions/655405/custom-protocol-handler-not-working-in-chrome-on-ssl-page
This works in chrome only:
window.location.assign("customprotocol://");
It will fail in an iframe so this is working:
var w = (window.parent)?window.parent:window
w.location.assign(service + '://' + data)
==================================================
Update: (weeks later)
==================================================
All of the examples of opening the custom protocol, including my own, have a "://" in the url. And this is what is causing the SSL warnings.
Turns out the solution is to change "://" to ":"
so do this:
src="x-myproto:query" .....
and the SSL warnings will go away.
==================================================
Follow: (after months of production use)
==================================================
This has been working well for chorme. Detect the browser and if chrome do this:
var w = (window.parent)?window.parent:window
w.location.assign('myproto://xyzabcdefetc')
For IE and other browsers I do something slightly different.
Note that browsers do impose a limit on how much data you can put in custom url protocol. As long as your string is under 800 chars this seems to be the magic number for which works in all browsers.
It looks like it's Google's locationbar parsing which is getting in the way.
The browser, however, does seem to handle custom URL schemes properly. Try this in your locationbar:
javascript:document.location = 'myscheme://whatever'
Any link on your page that uses the custom scheme should also do the right thing.
I found the solution that works with Chrome.
I use the IFRAME-way.
Example (with JQuery):
$("body").append('<span id="__protoProxy"></span>');
function queryWord(aWord)
{
var protoProxy = document.getElementById('__protoProxy');
if (protoProxy)
{
var word = aWord.replace('"','\"');
protoProxy.innerHTML = '<div style="display:none;"><iframe src="x-myproto://query?' + word + '"></iframe></div>';
}
}
queryWord('hello');
Here's a solution that also includes a redirect to the App Store / Play Store if the user doesn't have the app. It uses a setTimeout for this. It also makes use of an iframe to support more browsers. So this works on Chrome, and any other mobile browser. We use this as my company, Branch. Just modify the two links below to correspond to your URI and App Store link.
<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
window.onload = function() {
// Deep link to your app goes here
document.getElementById("l").src = "my_app://somepath";
setTimeout(function() {
// Link to the App Store should go here -- only fires if deep link fails
window.location = "https://itunes.apple.com/us/app/myapp/id123456789?ls=1&mt=8";
}, 500);
};
</script>
<iframe id="l" width="1" height="1" style="visibility:hidden"></iframe>
</body>
</html>
Again, this should work on any browser, thanks to the iframe.
If Chrome does not recognize the URL scheme, it defaults to a search.
This is what I see in Safari:
alt text http://img62.imageshack.us/img62/6792/clipboard02oh.jpg
and in Firefox:
alt text http://img138.imageshack.us/img138/9986/clipboard04xk.jpg
I believe the reason why Chrome defaults to search is that there are special google searches that use the colon.
E.g:
define: dictionary
filetype:pdf google chromium
This is one of the annoyances I have with Firefox, I have to jump to the "search box" rather than the address bar to execute these types of searches. Since Chrome does not have a separate search box like Firefox, IE and Safari have, this functionality is required.
Ajax requests won't get you around this.
Some weeks later ....
Looks like window.location.replace('myscheme://whatever') has full cross-browser support , works with chrome,firefox,safari,edge,opera see https://developer.mozilla.org/en-US/docs/Web/API/Location/replace
I am trying to make my gridview control in ASP.Net do a multi sort based on if the user pressed Ctrl key when trying to sort by clicking on a column name. The problem is that when I am using Firefox, if I click on a column name with Ctrl key pressed, the browser tries to open "javascript:__doPostBack('ctl00$ContentPla..." link in a new tab. IE and Chrome both don't do this unless the link is a real link.
Is there a way I can prevent Firefox from opening the link in a new tab and still cause the page to postback normally?
Thanks.
You need to capture the event of the Ctrl key being pushed down, using document.onKeyDown.
In your event handler, check if 'Ctrl' (key code 17) was pressed, as follows:
function document_keyDown(e) {
var KeyID = (window.event) ? event.keyCode : e.keyCode;
if (KeyID == 17) {
ctrlDown = true;
}
}
Here, I'm setting a 'ctrlDown' variable to true.
For the onKeyUp event, you can do the exact opposite:
function document_keyUp(e) {
var KeyID = (window.event) ? event.keyCode : e.keyCode;
if (KeyID == 17) {
ctrlDown = false;
}
}
Then, in the click event of your column elements, you can check if Ctrl has been clicked or not:
function columnElement_click() {
if (ctrlDown != undefined && ctrlDown == true)
alert("Ctrl + Click Received");
return false;
}
Make sure your column click handler returns false. Otherwise, the browser will execute the code, but then navigate to the address in the link's 'href' attribute.
Hope this helps.
(See also: http://www.geekpedia.com/tutorial138_Get-key-press-event-using-JavaScript.html)