I am having a strange problem in Google Chrome. I am including a js file via script src tag. I place alert('test') in the file and when I load the page in Chrome, It alerts twice. In every other browser it alerts once. Is there any known cause for this?
Here is the code that loads the JS:
<script type="text/javascript" src="/js/main.js"></script>
It appears this happens in Safari as well. Does not occur in IE and firefox.
I had this recently and eventually found out it was a chrome extension, specifically the cache killer extension
This might be helpful
Webkit browsers (Chrome, Safari) are loading pages redirected from .htaccess twice!
I've noticed this same problem in Chrome. I have some code that runs when the page loads and I have an alert inside that code. In every browser other than Chrome this code is run once, thus the alert displays once. In chrome the alert shows twice. I am not doing anything special, just running code when the onload event is triggered within <body onload="somefunction()">. I am not using links, iframes, or the Cache Killer extension. I tested it in Safari and the code is only being called once. This seems to be a Chrome specific problem.
I did some research and it appears this is a bug with Chrome. I found this link https://code.google.com/p/chromium/issues/detail?id=64810
Depending on your specific situation, this page may give you a work around for the problem.
The problem does not seem to be fixed as of yet.
Related
http://stevesouders.com/tests/ix-js.php
This page has 8000ms script before </body>. As I know, browsers render progressively, so it doesn't affect the visual result. Chrome and Firefox perform as I expected. But, Safari - both in macOS and iOS - doesn't.
It WAITS until the script is downloaded and parsed.
Very weird.
http://stevesouders.com/hpws/move-scripts.php
Here's another example. For this, Safari renders normally, as I expected.
Please explain this confusing behavior. I tried but even defer or async are not the solution.
It seems that the size of the content matters. The content of the first link is too small to render on Safari.
Please refer this thread: https://stackoverflow.com/a/16909228/2480917
I have a web page that has some client-side javascript that's fired via an onload() event handler in the body tag. This works fine when viewing the page in a browser. However, when printing the page via window.print(), the script doesn't run, and the fields don't display on the printed page in IE and Edge. Chrome and Firefox work fine, though. Has anyone seen anything like this? I tried searching via Google and Bing, and even here, but the only results I could find were people having issues printing, and not with whether or not JavaScript runs when the page is printed.
The problem is that the slider on the home and products page only works with firefox chrome and Opera. It just fails to move in either IE or Safari. The second issue is about how the site scales on mobile devices. I've looked into mobile event handling, but with less than great results.
http://dextersaltmedia.net78.net/
Copy-pasting the entire responsiveslides.jquery.js file into the console makes the thing work normally, so your problem is in
<script type="text/javascript" src="responsiveslides.min.js"></script>
The only issue is that the library module never runs, even though the library gets included as a file.
Put your script tags at the end of the page, that might work better. Or try placing the library script tag at the end alone.
Ideally though, you should just bunch up jquery and the library file in one .js file and include that one.
I am facing a really weird problem. I am calling window.print() from a javascript file. This is working fine in Safari, IE, Firefox... and until two hours ago it worked in Chrome, too. (Version 29.0.1547.57)
I did not change anything essential in my javascript file (really - I just removed some comments...), but what now happens is really weird: In Chrome, the print dialogue does not open when window.print() is called. Nothing happens. But then, when I press reload, the print dialogue opens immediately.
The behaviour in the other browser did not change. And while debugging in Chrome I can see that window.print() is called as expected and the script goes on after that. Only the print dialogue is not shown until pressing reload.
Has anybody ever experienced something like that? I also tried to call window.print() in setTimeout(), but this did not change anything. When I debug the content of the page which shall be printed appears to be perfectly loaded.
I am sorry to ask, but I did not find anything while researching. Any help would be appreciated!
Thank you!
Wasiim is right, there is a Chrome bug where window.print() does not work when there is a <video> tag in the DOM. I solved it by calling this function:
function printPage() {
window.print();
//workaround for Chrome bug - https://code.google.com/p/chromium/issues/detail?id=141633
if (window.stop) {
location.reload(); //triggering unload (e.g. reloading the page) makes the print dialog appear
window.stop(); //immediately stop reloading
}
return false;
}
From my experience this is due to continued background traffic, e.g. ajax calls and the like that prevent Chrome from feeling the that page is loaded completely. The reload breaks all traffic and thus the print dialog pops up.
This is a particular gotcha in Visual Studio 2013 where BrowserLink continually ticks away in the background.
This can be tested by disabling BrowserLink via the setting below:
<configuration>
<appSettings>
<add key="vs:EnableBrowserLink" value="false"/>
</appSettings>
</configuration>
I have exactly same problem with Chrome. You need to manually reload page:
Print
If by any chance someone is using VS2013 with chrome, this problem is caused by the BrowserLink funcionality.
see SO answer here
Similar behavior in Safari. It is caused by opened HTTP request(s) on background.
When any HTTP request is in progress, window.print() is executed successfully, but no dialog is opened!
You will have this issue, when you use a long polling (for server push). Because client will have already opened HTTP connection for a long time, window.print() will never work.
I am most certain you are experiencing this issue because you have a video element on your page - most probably an MP4.
If you disable this video / or have an OGV video instead, the printing should work fine.
It is a bug in chrome itself due to limitations of Chrome's video implementation. It is also important to note that if the user prints manually with ctrl-p / cmd-p, print functions correctly
http://code.google.com/p/chromium/issues/detail?id=141633
Hope this helps :)
I want to debug a javascript file that is embedded in the HEAD element.
I navigate to the site, see the code, and make a breakpoint:
(source: deviantsart.com)
But when I click on Reload, the script disappears and it doesn't stop at the breakpoint:
(source: deviantsart.com)
Debugging was working earlier so I know it works in general. What do I have to do so that Firebug always debugs my script?
I've noticed this behaviour before as well. It seems that it can happen if you refresh the page while the debugger is running (i.e. after you've hit your breakpoint and are stepping through code). This is far from conclusive, just something I've casually observed over time.
Also, I try to avoid having multiple tabs open with firebug active, as it seems to get confused.
Edit: just thought I'd add that I've seen this manifest itself in a few different ways:
the external script file does not appear at all in the scripts panel.
the external script file appears but firebug doesn't "see" it. You know this has happened because the line numbers beside the code where a breakpoint can be set won't be highlighted (used to be green but now appear to be just a darker shade than other lines). I've seen this happen with inline javascript on a HTML page (horrors!) as well.
the external script file is there, but you can only see a single screen full of code. Where "screen full" is the firebug panel viewport.
shut down firefox and then restart. sometimes firebug gets confused. also make sure you have the latest version.
You need activate the script tab
I'm not sure that having a <script> inside <head> (as opposed to, inside <body>) is actually legal HTML. If it's not, as I suspect, you can't fault Firebug for not supporting it well...!-)
The bugs in script processing that I know about are 1) jquery dynamic loading of scripts fails, 2) new Function() cannot be seen, 3) some kinds of document.write() cannot be seen.
Firebug processes script files in series with Firefox. This means that Firebug must be active when the page loads and it means that any exception in the path will cause the files to be mis-processed. If you opened firebug before loading and you still see problems, then the most likely fix is to install Firebug in a new Firefox profile. This causes you to get a completely fresh set of default options and you run Firebug without other extensions. As you re-add other extensions, look for problems in seeing scripts: then maybe you will discover what extension is interfering with the code path for processing scripts. I know this is a pain in the neck, but so is JS debugging without source ;-). We are working on testing with more Firebug and Firefox extensions installed to try to reduce these problems.
In our case it was the bundling of JS files.
It is not only FireFox, it is same for Chrome.
We moved the file out of the bundle and put it on the page where it needed to be referenced and it started working like charm.