I have a small code in my page with
<script type="text/javascript">
function doPost() {
document.forms["form"].submit();
}
function Func1Delay()
{
setTimeout("doPost()", 0);
}
....
<body onload="Func1Delay()">
I have this error in the console saying
Uncaught TypeError: Cannot call method 'create' of undefined
and on the right, it's due to the chrome extension MeasureIt. When I disable it, my script works. Is there a workaround for this problem?
The short answer is YES.
But the complete answer is NO, it's not Chrome, but some extension who interfere with your code.
For example:
1) A content script can add a listener and use stopPropagation. In this case your code won't receive that event. I can image a more specific scenario where the content script fails and therefore prevents other listeners to execute.
2) A content script can mess with your page's elements. It can remove some, and add its owm. What would happen if the extension add a SCRIPT element with a var or function named exactly the same that one of yours?
We cannot be sure about how "well" the extension's code is written.
By the way, there is a lot of Chrome's extensions that interfere with pages. Some months ago Skype extension for Chrome was found guilty of interfere and destabilize web pages and video playback in that browser.
Related
We have a DotNetNuke module running in an instance of DotNetNuke 5.4.4, installed on "Server A", a Windows Server 2008 R2 Standard machine with IIS 6.1 and Internet Explorer 11.
We're accessing our DotNetNuke module from "Server B", running Windows Server 2008 Standard, with Internet Explorer 9.
The issue happens when we click an anchor html element that has an onclick attribute, while accessing our module on Server B.
The anchor with the onclick is like:
<a onclick='OpenWindow("/DotNetNuke/DesktopModules/Module/View.aspx?dt=%c2%b2%c2");return false;'
href="http://000.00.0.0/DotNetNuke/DesktopModules/Module/View.aspx?dt=%c2%b2%c2"
target='_blank'
jQuery1431968126278="42">Doc name (SSN-SS-SSNN)</a>
And the OpenWindow function is like this
function OpenWindow(url) {
window.open(url, '', 'top=15,scrollbars=yes,menubar=no,height=800,width=800,resizable=yes,toolbar=no,location=no,status=no');
}
As you can see we have an anchor element, with an onclick attribute, where it is supposed to call the OpenWindow javascript function, then return false, so the default action for clicking an anchor (browse to the href) does not happen.
When we click this link though (ONLY on server B), we get no popup window, no breakpoints in the OpenWindow function are hit, and the browser navigates to the href by opening a new tab (View.aspx). This suggests to me that the OpenWindow function referenced by the onclick attribute is not even running for some reason, even though it is on the anchor element, and works on any other server.
What I've tried
I compared the security settings, web.config files, and DotNetNuke settings between the Server A DotNetNuke and my local developer DotNetNuke instances, and found no differences in setup.
I compared the Server B Internet Explorer security settings to my security settings, and found no differences in setup.
On the advice of comments on this question, I tried changing the anchor tag to a span tag instead (removed href and target attributes), and I am seeing the same behavior. It works on Server A and Dev, but doesn't do anything on Server B now. I think the core issue is that either the onclick attribute is not being recognized, or is being blocked somehow.
I've now gone further and changed most of the <a>...</a> tags into <span>...</span> tags, with specific classes, that I then attach jQuery(...).live('click', ...) handlers to (using jQuery 1.4.2). That is allowing the clicks to work, but I still haven't resolved why the onclick attribute is being ignored.
What's weird..
If I open the developer tools (IE9), then click the "Edit" button to turn edit mode on and off again, all of the onclick attributes on anchor tags and img tags start working correctly, until I reload the page.
If I edit the onclick handler in any way manually through the developer tools, like say removing the return false; from the onclick handler, it will work, but if I put the return false; back to make it like I never changed anything, it stops working again.
What I'm trying to figure out
I am hitting a wall with what to check to figure out this issue. I can't reproduce it on my developer machine, and it works on Server A as well, so the code is working perfectly fine.
I'm thinking there must be a setting that I am overlooking somewhere, but where? I have no idea what else to check at this point, and I'm looking for ideas.
I don't have an exact answer, but I can give you the general idea of what is happening and why.
The two servers are not getting identical content -- perhaps they are pointed at different CDNs, perhaps one has an old file of a JavaScript file somewhere -- you'll have to walk through them one by one.
Something, somewhere, is applying an onclick handler to all of your anchor tags.
At first I thought it was something attached to the body element and targeting your links, but I ruled that out. The fact you can edit the HTML and save it and then the link works means you are detaching whatever was attached to that link element.
I would:
Save the entire web page from Site A
Save the entire web page from Site B
Run a diff tool against the two directories.
Have you tried to call window.open directly from the onclick attribute? It could be that the function is not loaded at the time the link is clicked, so it produce an error, so return false is not called, and the link proceed with its default behaviour (in this case open a tab).
If this is the case, look at the loading order of that function, or try placing it in a different part of your code (maybe within the onload event).
Check if you're showing JS errors in your Internet Options.
It might be a bit childish, but since you are opening a window as a Pop Up there can be issue that the URL from the site might be blocked from the browser. It should work at all times if you just replace
window.open(url, '', 'top=15,scrollbars=yes,menubar=no,height=800,width=800,resizable=yes,toolbar=no,location=no,status=no');
with
window.open(url);
Have you tried modifying your tag to:
<a href='javascript:MyFunction(this);' data-url='YourUrl'>Name</a>
MyFunction: function(obj) {
var element = $(obj);
window.open(element.data("YourUrl"));
}
Note that if the user's browser is configured to open Windows as tabs, there is not a workaround. target="_blank" is the best way that I know of to achieve this and enforcing browser behavior via GP.
Sounds like it's something not in the scope of the code you have provided. You mentioned opening the IE9 dev-tools makes it work, I suggest try adding console -polyfill, something like:
if(typeof(console)=="undefined") {
var console = {
log : function() {},
error : function() {},
debug : function() {}
};
}
Just in case some of your code is outputting things into the console and the JS code stops working after that event. Could be some external library, which after loading starts outputting things to the console - that might work differently on different servers because of caching settings and/or network latency.
NOTE: to test this properly, remember to add this into a SCRIPT tag before you load any JS code or import any external library.
I have been using an iframe to embed content from a different site (on the same domain) into a web page. Up until now, my clients have been accessing the site using Internet Explorer 7 and everything has been working completely fine...they click a button, the iframe src property is updated and the content is loaded.
After some recent software changes, the clients are now required to access the web page in IE 8/9/10. When they click the button in any of these later version of IE however, the client page IS successfully loaded into the iframe, but only for a very brief period (less than half a second). Essentially the page is loaded but then immediately unloaded - I tested this was the case by displaying some alerts when the window load/unload events are fired.
I have tried and failed to find the cause of the problem using the browser debugging tools. I can't see any errors (or warnings for that matter) relating to the issue, and the rest of the site is functioning normally. I am aware that there have been several changes to the way iframes are handled in later browser versions, but I'm not sure whether this is the cause of the behaviour that I am observing. Is it possible that the newer browser versions are telling the iframe to unload?
Does anyone have any ideas as to what might be causing this problem (am I even on the right tracks here)?
Any help would be greatly appreciated.
Just so that you are aware, this behaviour is reflected in both Chrome and Firefox (these are also going to be supported).
Edit:
For the sake of testing I have been injecting a very simple html file as the client page and I still experience the exact same problem:
<!DOCTYPE html>
<html>
<head>
<script type="text/javascript">
function clickFunction() {
alert("Hello World!");
}
</script>
</head>
<body>
<button id="myButton" onclick="clickFunction()">Click Me</button>
</body>
</html>
This html is injected into an iframe that is embedded on my web page. As far as I am aware there is nothing unusual about the iframe:
<iframe id='geode_iframe' style='width:100%;height:100%;left:0;top:0;position:fixed'></iframe>
When the button on my page is clicked, the following code is used to set the src of the iframe:
document.getElementById('geode_iframe').src='http://BI0002/IRSGeodeClient/Basic.html'
In theory this operation should be relatively straightforward, hence why I thought it more likely that I was unaware of some change in iframe behaviour.
I have managed to track down the cause of the problem at long last. The panel in which the iframe was embedded was actually being created twice, which I think was confusing the browser when I called document.getElementById (since I had two panels with the same id).
I'm not sure exactly why this behaviour was occurring...perhaps IE7 and IE10 use a different post back model and I was getting an extra postback which was causing the creation code to execute again.
Thanks anyway.
Chrome developer tools allows you to edit javascript in the browser if the javascript is in a .js file. However, it does not seem to allow me to edit javascript that is embedded in an HTML page. ie:
<script type="text/javascript>
// code here that I want to debug/edit
</script>
This is a big problem for me as I have quite a bit of embedded javascript in a certain page.
Similar to this question: Edit JavaScript blocks of web page... live but this is about firefox, not chrome.
How can I edit javascript embedded in an HTML page using Google Chrome Developer Tools?
Actually chrome allows to do that, choose HTML files in Sources tab in Developer tools window. You will see HTML instead of javascript and simply add breakpoints in the <script> tags. Also you can add debugger; command to script what you want to debug. For example:
<script>
// some code
debugger; // This is your breakpoint
// other code you will able to debugg
</script>
Don't forget to remove debugger;'s when you want to release your website.
I had a difficult time locating the file that had my inline/embedded javascript. For others having the same problem, this may or may not be helpful...
Using Chrome 21.0.1180.89 m for Windows
All files are shown after clicking that very discreetly placed button. See:
Now you may begin debugging...
None of these answers have worked for me.
What works for me is if I have my javascript on the page already loaded, I can copy that javascript, edit it, then paste it in the console and it will redefine any functions or whatever that I need to be redefined.
for instance, if the page has:
<script>
var foo = function() { console.log("Hi"); }
</script>
I can take the content between the script, edit it, then enter it into the debugger like:
foo = function() { console.log("DO SOMETHING DIFFERENT"); }
and it will work for me.
Or if you have like,
function foo() {
doAThing();
}
You can just enter
function foo() {
doSomethingElse();
}
and foo will be redefined.
Probably not the best workaround, but it works.
Go to the Elements tab, find your script, right click on the part you need and choose "Edit as HTML".
If Edit as HTML doesn't appear, double click the node and it should become highlighted and editable.
Solution described here: https://greatrexpectations.com/2014/01/22/chrome-dev-tools-inline-dynamic-javascript
Add the 'sourceURL' directive in your inline/embedded script like this:
<script type="text/javascript">
...script here...
//# sourceURL=helperJavaScript.js
</script>
Then this script will appear in the page Sources and you can debug and edit it similarly to js loaded from a URL source
Ok, I'll do my best.
There's this page http://tiu.ru/image/tmp/test_2.html , which looks differently in Opera then in Chrome and Firefox (maybe others).
It evaluates a javascript code inside <div></div>, that does document.write("") of a piece of another HTML code with <script>, that evaluates JS code that asks Google Ads to write ads.
Google Ads writes it's container and container's content (which loads advertising from Yandex) ((maybe you'll need to disable adblock to see ads, but you can just view the screenshot)).
And the problem is that in Opera it writes that content outside the original div somehow.
Screenshot of result for Chrome:
Screenshot of result for Opera:
If you take that code inside document.write() and put it just as usual HTML code -- everything works well. See http://tiu.ru/image/tmp/test_3.html
I can't figure out how to debug that google ads code, that's why I ask for help. Thank you.
p.s.: you can save page to localhost somewhere and open it, ads won't be loaded, but DOM tree will be the same wrong.
Thank you very much!
Well, you add a script tag with document.write() that does document.write() to add the one that calls GA_googleFillSlot, which itself does document.write() to add a SCRIPT with SRC set to a doubleclick.net URL which calls back into google_ads.js to trigger another document.write() that adds an inline SCRIPT containing another document.write() call to add another external script, this time loading context.js from an.yandex.ru, and it looks like context.js also contains code to add yet two more external scripts to the document. But at this point the damage already happened: although a loading external script inserted with document.write() should block parsing, something odd happens when the doubleclick.net script loads and calls back into google_ads.js that makes Opera close the parent DIV.
Let's see what the DOM looks like the moment DoubleClick calls back to google_ads - by setting a breakpoint in GA_googleSetAdContentsBySlotForSync and using Opera Dragonfly. There we go: on entering this script, the DOM is still OK, the DIV is not closed - but when this script thread does document.write() to add <div id=google_ads_div_ru__context_informers_addon_360x90_ad_container> with comments, markup and scripts inside, something about that new content makes Opera believe it needs to close the former document.write()-inserted DIV. It's a parsing bug deep inside the handling of multiple nested document.write()s, I guess.
This will work fine with Opera's upcoming HTML5 parser. If at all possible for you, don't worry about it and wait until Opera 12 sorts it all out.
Opera has a strict XHTML parser. Try wrapping your javascript in CDATA tags so the parser will ignore the < and & characters as well as any other illegal characters in your script:
<script type="text/javascript">
/* <![CDATA[ */
// put your js code here
/* ]]> */
</script>
EDIT: as this problem is now "solved" to the point of working, I am looking to have the information on why. For the fix, see my comment below.
I have an web application which repeatedly downloads wav files dynamically (after a timeout or as instructed by the user) into an iframe in order to trigger the a default audio player to play them. The application targets only FF 2 or 3. In order to determine when the file is downloaded completely, I am hoping to use the window.onload handler for the iframe. Based on this stackoverflow.com answer I am creating a new iframe each time. As long as firebug is enabled on the browser using the application, everything works great. Without firebug, the onload never fires. The version of firebug is 1.3.1, while I've tested Firefox 2.0.0.19 and 3.0.7. Any ideas how I can get the onload from the iframe to reliably trigger when the wav file has downloaded? Or is there another way to signal the completion of the download? Here's the pertinent code:
HTML (hidden's only attribute is display:none;):
<div id="audioContainer" class="hidden">
</div>
JavaScript (could also use jQuery, but innerHTML is faster than html() from what I've read):
waitingForFile = true; // (declared at the beginning of closure)
$("#loading").removeClass("hidden");
var content = "<iframe id='audioPlayer' name='audioPlayer' src='" +
/path/to/file.wav + "' onload='notifyLoaded()'></iframe>";
document.getElementById("audioContainer").innerHTML = content;
And the content of notifyLoaded:
function notifyLoaded() {
waitingForFile = false; // (declared at beginning of the closure)
$("#loading").addClass("hidden");
}
I have also tried creating the iframe via document.createElement, but I found the same behavior. The onload triggered each time with firebug enabled and never without it.
EDIT:
Fixed the information on how the iframe is being declared and added the callback function code. No, no console.log calls here.
Old question but for future reference:
As far as my experience onLoad is not called for file downloads. A way to solve it is to use cookies like they do here http://gruffcode.com/2010/10/28/detecting-the-file-download-dialog-in-the-browser/
Here's an example that works for me, without Firebug open (tested in FF 3.6.2 Mac): http://www.jsfiddle.net/Kukry/
I'm using the jQuery .load() event instead of onload.
var iframe = $("<iframe/>").load(function () {
alert("loaded");
}).attr({
src: "http://code.jquery.com/jquery-1.4.2.min.js"
}).appendTo($("#thediv"));
Note that I'm loading a JavaScript file, not an audio file, so that might make a difference.
Maybe you call some Firebug internal function, like console.log(), somewhere? In that case, Firefox will threw an exception which can stop the execution if Firebug is not active.