I am following the given steps to try,
"Getting Started with the Closure Library".
https://developers.google.com/closure/library/docs/gettingstarted
Step 1: Download and Setup the Closure Library
Step 2: Create a JavaScript file that uses the Closure Library
Step 3: Create an HTML file
Step 4: Say Hello (with the created file) to the Closure Library.
Yet when using Chrome as the browser, on a PC, these steps yield a blank screen.
Is there some restriction with the example in Chrome? The example
was saved on C: Drive, in a directory for the closure-library,
C:\hw3_1\closure-library. Note here, this is not a homework problem,
yet a trial of the closure-library.
Right-clicking the screen, the following code is displayed:
As a test, when clicking on the hypertext, "closure-library/closure/goog/base.js"
the file opens in the browser. Likewise, clicking on
the hypertext for "hello.js", this file also opens in the browser.
The example simply yields a blank screen.
Is there a solution available?
The problem was when I ran hello.js I got blank Chrome output (the same as the Original Poster) But I was fortunate enough to check the browser debug.
Access to XMLHttpRequest at blah blah closure-library/closure/goog/debug/error.js' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.
If anyone else gets this look in Chrome>More Tools>Developer Tools>Console you will see the above type message alongside your "blank screen". See this link for details: Cross-Origin Resource Sharing (CORS)
The solution is to launch a single Chrome session using the following in Command Window (Run as Admin)
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir=~/repos
Of course these are my settings. Use Win Explorer to find your own chrome.exe and copy "Address as text" to a Notepad page. Assemble the remaining instruction - stating the folder where your .js & .html "Getting Started with the Closure Library" files are.
Paste the completed instruction string into the Command window. This should immediately launch a new Chrome session.
When the Chrome window launches it will have a gentle warning. Just type in your path & filename into the URL space.
Mine was file:///C:/Users/david/source/repos/hello.html
From here you can see the text Hello world! contained within the sayHi() function of hello.js showing in the HTML output.
This will let you move on with Google Developer Getting Started with the Closure Library
Related
I cannot figure out how to debug my simple extension. Script (a content script) loads (because the first console.log call shows in the tab's console) but then nothing. There's no error what so ever and no second console.log call.
My question is not about solving my code issue (there surely is one, if only firefox would tell me where), it's about finding the place where warnings/errors about the add-on are in firefox (like 'sdfsdf has no object property ...')
about:debugging is no help, the console it can open shows some errors (example: 'Error: Service "domainInfo" is not available. Make sure it appears in the "requiresServices" property of the module's background where is it used.') that have nothing to do with what I'm trying to do (I can tell from the source and nature of errors)
// start of file
console.log('I AM LOADING');
// simple DOM manipulation code here...
console.log('I AM LOADED');
// end of file
The content scripts are supposed to be debugged with the DevTools instance attached to the web page.
However, as you noticed, the errors in the content script are not reported in the tab's Web Console due to a bug. (As of Firefox 70.)
As a workaround you can:
use try..catch with logging,
check the Browser Console (which does show error in the content script)
use the Debugger's "pause on exceptions" option.
I've created an addon using the addon SDK and installed it in Firefox (version 35.0.1). The addon has the following files -
data/login.js (content script file)
lib/main.js (main addon code)
test/test-main.js (auto-generated)
package.json
In the main addon code I'm creating a panel, and the content script file is loaded using the contentScriptFile property of the panel. However when I launch the addon debugger, I'm able to see only the main.js script and not the content script. I've checked that the xpi file actually contains the content script file. So why isn't the debugger showing it?
I think I found it (using Firefox Developer Edition 42.0a2 though).
Open the Default Web developer Tools (Ctrl+shift+I)
Go to Settings (cog wheel top right)
Enable "Advanced Settings" > "Enable worker debugging (in development)"
Enable "Inspector" > "Show Browser styles" (for seeing your content style (files))
Reload the page
Try using the browser toolbox or the browser content toolbox which is not scoped to a single addon.
Afaik the addon debugger only shows scripts running in the same compartment as the addon main, which may miss scripts running in sandboxes/other compartments.
Its probably an error in your content script code that prevents the file from appearing in the debugger file list. I had this problem and it's difficult to find these errors as the Firefox error log often doesn't refer to the which file is in error or the line number. Check for unpaired braces that kind of thing
I need to trace redirect using network tab, but it works only if I open web inspector and then reload page. Unfortunatly, I open this page from external native program and need to found, which URL is passed to browser. Is it possible to do this? I bneed to do this on Windows 7.
As far as I know this isn't possible. The complete list of up-to-date chromium command line switches can be found here: http://peter.sh/experiments/chromium-command-line-switches/
I thought you might be able to to get something working using --wait-for-debugger-children, giving you enough time to open the developer tools before the page loads, but setting that flag also gives the developer tools a 1 minute delay before loading.
I recently installed Webstorm for my html5 / css / javascript project. I have been unable to run or debug sucessfully from inside the IDE. I have a typical web setup with and index.html file and css and js folders. I'm using MAMP for my local web server and it starts and runs my site no problem when run inside my browser. I can't run because the "Run" button is greyed out. When I try to debug (I set a breakppint in a js file that I know should execute up front) Firefox opens but just shows (http://) with no full path to my index.html AND I see a message in the IDE: Remote URL isn't specified for 'kazaam_localDB.js' so breakpoints won't work in it. Set remote URL for 'kazaam_localDB.js
I did configure my local server when I created a "new project from existing files". I did notice the first time I did try to debug a message cam up saying it needed to configure Firefox with an add-on or extension, but I'm not sure that succeeded because I can't debug...
Ok here is what you have to do:
Ok stop and exit Firefox THEN retry debugger from webstorm. You should now see now the extension has been installed in Firefox.
When you set breakpoint in js file in a local file WebStorm it needs to know which URL corresponds to that file on the server. To specify URL mapping for local files you can either click on 'Set remote url' link in the warning popup or open Run | 'Edit Configurations' dialog and select the run configuration under 'JavaScript Debug' node.
I have been developing an AJAX application using jQuery and Microsoft Seadragon technology.
I need to have access to the html5 canvas function toDataURL.
With Google Chrome, the same origin rule applies to this function which means that a page run locally (with the file:/// in the URL) failed to satisfy the same origin rule and an exception is thrown.
With Chrome 7, starting the application with --allow-file-access-from-files option, allows to call canvas.toDataURL() from local files.
However, it seems that starting the Chrome Beta 8 with the same option (--allow-file-access-from-files) does not allow the call canvas.toDataURL() on the local file.
Does Chrome gave up on the --allow-file-access-from-files option or it has just been disabled since it is a Beta release and not a full release?
Thanks!
Looking at the issues for this shows that the whole --allow-file-access-from-files thing was rushed.
"Firefox does it.."
"How can we do it?"
some time passes
"Here are the patches"
"Passes! On trunk wonder what happens in the next dev release"
"Ahhh it's broken" "Use the command line option" "ok"
"We shipped!"
"WTF guys? You broke all my stuff! Why didn't you tell us earlier?"
silence
On to your Problem
Indeed it seems that this is something special to the beta, I'm using Chrome 8.0.552.5 dev here and --allow-file-access-from-files works like expected, I've also tested this with Chromium 9.0.592.0 (66889) were it also works as expected.
I suspect there have been some changes on the dev branch. Unfortunately, finding something on chromium's issue tracker is nearly impossible.
Did you close all chrome instances before opening with the command line argument? You have to do that to make that parameter work.
To summarize all answers so far.
Before running chrome, make sure there are no chrome processes running.
Windows
-allow-file-access-from-files
(with one dash)
Linux
--allow-file-access-from-files
(with two dashes)
I've found a way around the issue using a JavaScript/Flash approach. If flash is compiled in the Local Only security sandbox, it has full access to local files. Using ExternalInterface, JavaScript can request a Flash Application to load a file, and Flash can pass the result back to JavaScript.
You can find my implementation here: https://code.google.com/p/flash-loader/
The trick that woked for me is that you have to give the absolute path of the file and not just file name in your HTML code. e.g file://... instead of direct name even though you are accessing the file in the same directory. It will work!