New at Chrome Apps. Using cca and CADT for mobile development.
In the following code, why is jQuery not immediately available? Is there some async magic being auto-applied?
I don't have this behavior in a vanilla cordova project.
<script type="text/javascript" src="js/jquery-2.1.1.min.js"></script>
<script type="text/javascript">
setTimeout(function()
{
console.log($); // $ is jQuery
}, 1000);
console.log($); // $ is undefined
</script>
Our current bootstrap code will not load the html of your chrome app windows in a way you typically expect from a browser. The reasons are long, but the short story is that we have to bootstrap to set up the environment, then inject the content around the bootstrap.
One of the consequences is that scripts do not block dom content loading. I guess another consequence is that inline script execution is not delayed until preceding scripts have loaded.
We may be able to fix this bug, I'll take a look. I've filed: https://github.com/MobileChromeApps/mobile-chrome-apps/issues/482
Thanks for reporting the issue!
Related
I've spent more time on this than I care to admit but was hoping for some help in understanding the cause of the problem. I have a basic HTML web resource in Dynamics 365 (v9.1.0.9228) and in order to get the global context I must include the following:
<script src="ClientGlobalContext.js.aspx" type="text/javascript"></script>
https://learn.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/getglobalcontext-clientglobalcontext.js.aspx
The problem is that when I do... the Chrome debugger loses its place in the document. The execution stops at the breakpoint(s) but the current line is not highlighted this means no way to step into/over the lines or indeed know what line we are on at any given point. I can see however that the code is being executed due to my output to console (See code in footer).
I have tested this across:
Multiple D365 online instances (v9.1.0.9228)
Multiple development machines running Chrome (v77.0.3865.90)
Literally stripped back the code to very basic HTML. Interestingly, this issue does not occur in IE? The only workaround I have found is rather than having inline JS within the head tags place it a separate file instead and reference from the HTML web resource, Chrome then seems to have no issues in stopping on right line and highlighting the correct line as we debug BUT only functions within that library. If the HTML web resource has inline script the issue will still be present within that scope.
head
<script type="text/javascript" src="ClientGlobalContext.js.aspx"></script>
<script type="text/javascript">
function registerEvents() {
debugger;
console.log("in registerEvents v2.0.3");
testButton = document.getElementById("test");
testButton.onclick = test;
}
function test() {
debugger;
console.log("in Test v2.0.3");
}
</script>
body
<script type="text/javascript">
registerEvents();
</script>
<p>In chrome debugger v2.0.3</p>
<button id="test">Test</button>
I would like to understand if I am doing something wrong here as it seems to be a bug within Chrome DevTools itself given this works on all other browsers when debugging? The actual code here is almost irrelevant as the issue occurs whenever "ClientGlobalContext.js.aspx" is referenced, if we comment out that line the Chrome debugger works as expected.
I am trying to load coffee script inside a sample.coffee file along with the coffee-script.js file and perform some simple operations on the HTML. But i am not able to load the sample.coffee file.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<script src="sample.coffee" type="text/coffeescript"></script>
<script src="coffee-script.js" type="text/javascript"></script>
</head>
<body>
</body>
</html>
Here is the coffeescript code inside sample.coffee
message = "Welcome to Coffeescript"
alert message
I referred the blog http://forgivingworm.wordpress.com/2010/09/27/running-coffeescript-in-browser/
I trying to run this in MVC4 project on .cshtml. So I am running under MS world.
I am not sure if this is possible or not? any insight into this would be greatly appreciated.
I am able to solve this issue by using the CoffeeSharp http://tomlokhorst.github.com/CoffeeSharp/ It gives handler for .coffee files also converts the coffeescript to javascript on the browser.
Also I am able to compile the coffeescript to javascript during the build event itself which solves deployment and performance related issues.
I dont think this will work like you tried it.
You will need something like requirejs and the coffeescript loader
at https://github.com/jrburke/require-cs.
However I would strongly discourage this and rather have it compiled before loading into the browser (require.js is encouraged though). You might find grunt.js helpful for "building" your app before deploying.
That html works fine for me. I used the coffee-script.js found here: https://cdn.rawgit.com/jashkenas/coffeescript/1.11.1/extras/coffee-script.js and my sample.coffee is:
x = ->
alert("hi")
x()
If you open the Javascript console, do you see any errors?
I have a tinyMCE plugin (for the post/page editor) that I am loading from my Wordpress plugin that needs to have several external javascript files loaded in order for my tinyMCE plugin to work.
In Wordpress 3.3.1 I can just register and enqueue the scripts from the mce_external_plugins filter but any Wordpress version below that doesn't load the scripts.
Anybody have experience in this?
The method that I found to work with my problem is by hooking to after_wp_tiny_mce and then in the callback, calling wp_print_scripts directly. It still handles all the dependencies of the scripts.
Also, because wp_localize_script won't work with this method due to the scripts not being enqueued, I am echoing my objects directly above my calls to wp_print_scripts like this:
<script type="text/javascript">
/* <![CDATA[ */
var MyLocalizedData = {"foo": "barito"};
/* ]]> */
</script>
EDIT :
This fix will only work in Wordpress >= 3.2
Can someone explain what happens after the java code is converted to Javascript by the GWT compiler?
how will the compiled javascript reach the client browser and when does this happen.
Well from your server, you serve a html page which should contain a tag that points to your compiled javascript.
Example of what the script tag would look like
<script type="text/javascript" language="javascript" src="http://example.com/js/project/project.nocache.js"></script>
The GWT compiler generates output files as described here.
At a very high level. There is a very tiny loader file (the .nocache.) which you should include in a script tag in your page. This file's only job is to determine the correct compiled application code files to request from the server. This load happens asynchronously after the nocache script has loaded.
I've encountered what seems like a chicken & egg problem, and have what I think is a logical solution. However, it occurred to me that others must have encountered something similar, so I figured I'd float it out there for the masses.
The situation is that I want to use dojo's addOnLoad function to queue up a number of callbacks which should be executed after the DOM has completed rendering on the client side. So what I'm doing is as follows:
<html>
<head>
<script type="text/javascript" src="dojo.xd.js"></script>
...
</head>
<body>
...
<script type="text/javascript">
dojo.addOnLoad( ... );
dojo.addOnLoad( ... );
...
</script>
</body>
</html>
Now, the issue is that I seem to be calling dojo.addOnLoad before the entire Dojo library has been downloaded the browser. This makes sense in a way, because the inline SCRIPT contents should be executed before the entire DOM is loaded (and the normal body onload callback is triggered).
My question is this - is my approach sound, or would it make more sense to register a normal/standard body onload JavaScript callback to call a function, which does the same work that each of the dojo.addOnLoads is doing in the SCRIPT block. Of course, this begs the question, why would you ever then use dojo.addOnLoad if you're not guaranteed that the Dojo library will be loaded prior to using the library?
Hopefully this situation makes sense to someone other than me. Seems like someone else may have encountered this situation.
Thoughts?
Best Regards,
Adam Rice
You're doing it correctly. External Javascript files are loaded and executed synchronously in order, so by the time it reaches your dojo.addOnLoad( ... ); Dojo has loaded. Use dojo.addOnLoad instead of window.onload for two reasons:
it fires earlier, because it utilizes DOMContentLoaded
it handles asynchronous loading of dojo.require by postponing the execution until all required scripts have been read
Explained in DojoCampus as (dojo.addOnLoad):
dojo.addOnLoad is a fundamental aspect
of using Dojo. Passing addOnLoad a
function will register the function to
run when the Dom is ready. This
differs slightly from document.ready
and body.onload in that addOnLoad
waits until all dojo.require() (and
their recursive dependencies) have
loaded before firing.
This might have nothing to do with your problem, but ive just had a case where I had the same symptoms. For me everything worked fine for Firefox, Chrome etc, but not IE8.
I was getting what looked like dojo not being loaded, an error in IE8 saying that dojo was undefined (but not all the time) and i could strip everything down to just style sheets and importing dojo and still get the error.
I was running a local google app engine development server. This looks to be based on pythons SimpleHTTPServer which in turn uses SocketServer.BaseServer. This has BaseServer.request_queue_size which defaults to 5 - i couldn't find anything in app engine which overrode this value so i guess the development google app engine server has an upper limit of 5 connections.
Using regedit and going to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
“MaxConnectionsPerServer”=dword:00000010
“MaxConnectionsPer1_0Server”=dword:0000010
This shows that IE was going to try and open up to 10 simultaneous connections. I edited these two keys and made them 2 and restarted the computer, the problem went away.