My deployed JavaScript application raises an exception. The Javascript code is obfuscated. I would like to know, which line in original source code raises an exception. Source maps are not deployed, so Chrome Devtools can't connect them. I may have source maps on my localhost.
So basically I would like to add source maps from my machine to the browser in order to know the line number, where exceptions occurs.
I tried Add Folder to Workspace and Map to File System Resource. It does not help. An exception is visible in browser's console, but it still points into obfuscated javascript source and desired line number is not detectable.
I may do something wrong. Any help is appreciated (including additional extension or other browser usage).
As powerful as Workspaces are, there are some limitations you should be aware of.
Limitations
Only style changes in the Elements panel are persisted; changes to the DOM are not persisted.
Only styles defined in an external CSS file can be saved. Changes to element.style or to inline styles are not persisted. (If you have inline styles, they can be changed on the Sources panel.)
Style changes in the Elements panel are persisted immediately without an explicit save -- Ctrl + S or Cmd + S (Mac) -- if you have the CSS resource mapped to a local file.
If you are mapping files from a remote server instead of a local server, when you refresh the page, Chrome reloads the page from the remote server. Your changes still persist to disk and are reapplied if you continue editing in Workspaces.
You must use the full path to a mapped file in the browser. Even your index files must include .html in the URL, in order to see the staged version.
https://developers.google.com/web/tools/setup/setup-workflow
Related
I'm making a local web page (.html) that loads a few .js files and am having trouble using Google Chrome's Developer Tools.
Definition
The problem I'm having has to do with the Source Panel: I have one source tab open with a specific file and when I open this file by clicking the console or the source file at the left, randomly a duplicate is created instead of just redirecting it to the one already open.
Both will have the same file-path:
Both will allow me to write and save the file (even showing/hiding the asterisk correctly)
Only one of them will correctly save the contents to disk.
I have to fix it by closing both files and opening it again, but sometimes I can't see that there is a duplicated file and it causes me to fix a problem only to find out that the file wasn't actually saved, reverting completely every change I made to that file when I refresh the page.
Example of the problem
The most common appearance of the bug is when I'm doing the following:
I identify a console.warn / console.error / syntax error log in the console
I click the line that caused that log (at the rightmost of the console) and I'm redirected to the source panel, where a new source file tab opens and I begin editing it.
Somewhere in the source tabs is another source file of that same file (with the same filepath): That tab should be the one I was editing: only this original tab will correctly save changes made to the file.
I fix the random javascript problem in the file that I was lead to by clicking the console.
I hit Ctrl+S (or Right Click > Save), the asterisk that indicates a unsaved file disappears. At that point Chrome expects to have saved the file successfully, but it didn't (I can check by opening the file in Notepad)
I hit F5 to refresh the page.
Chrome loads the old, unsaved file, erasing all the changes I made in the source file.
Sometimes the very same steps doesn't create a duplicate file, but all I have to do is refresh and try again until it does. Recreating this bug is a matter of chance, I can't predict or pinpoint its causes either.
When refreshing the page with the Dev Tools open, there's a small chance that it will creates a broken mapping, where the mapped project becomes only partially mapped
even though it was fine seconds before: (only restarting chrome fixes that)
This last paragraph may or may not have something to do with the problem but I can clearly select and open the "fake" file and the "real" file even though they have the same file path.
I made this gif to show how the file paths are identical to each other in the Dev Tools: http://i.imgur.com/ULlbskO.gif
Details of the setup
I'm using the local file system (file:///) strictly, there is no localhost or server being used to host my application, it is pure HTML + Javascript.
I'm using Google Chrome 57 for Windows without any extensions, but I've been having that problem since December, 2016.
My project was mapped by adding the folder to the workspace and mapping it to a local file, which used to work in the past.
Here's a picture of my configurations: http://i.imgur.com/IEmE3zG.png
Things I've tried
Clearing Chrome's Cache
Removing the project from the Source Panel workspace and adding it again
Reinstalling Chrome
Moving the project path to somewhere else
Searching on Google
Letting go / Accepting defeat (I've grown too dependent on the tool)
Waiting 2 months for someone to have this problem too and post it somewhere in the internet
Questions I need help with
Can I minimize/fix this problem in any way?
Has anyone dealt with this before?
Does someone know if this is a Chrome bug or am I doing something wrong with my workflow?
Found the answer myself after several months working with web development.
The duplicated file has been fixed in Chrome since the time I made this question, but files keep loosing "connection" with the local file system (green dot that marks them as sync'd with local) randomly, which made me investigate and I finally found the reason:
What's happening is that Dev Tools is trying to save the file and, when it retrieves it it loads from cache (because my local web server was sending cache-specific headers), which makes the browser think that file file is not actually the one it saved, so it stops its syncronization!
To solve it, all I had to do is ensure my local web server is disabling any form of cache for my javascript files, which I can check from the network panel:
My local web server was sending cache headers for 1 hour, which made chrome open the cached file, which was different from my edited file which was an indication that the file is not the one it saved.
After changing the server to serve static content without the cache headers, everything went smoothly and files kept sync'd correctly!
I am debugging a Javascript file that is deeply nested in the source tree. The URLs I have to drill down through are extremely hard to memorize since the JS source I want is loaded inside an iFrame that has been loaded by an Add-In API.
Is there a way to "pin" or "bookmark" a reference to the Javascript source from within the Chrome debugger, so I don't have to drill down the sources tree every time I reload the web page just to get back to that source file again?
There's a few different options, but there's no specific "pinning" feature in DevTools.
The files opened in the Source tab persist between browser sessions, so you could just keep it there and not close it. That's the first obvious thing I noticed.
If you know the file name, use Cmd+O (Mac) / Ctrl+O (Windows/Linux) to open the 'Search by filename' box, and then you can open the file directly instead of via the tree.
If you want to actually debug the file, do what Christiaan suggested, and add a debugger; statement to your source code. This will automatically open the file in the Sources panel, and break on whatever line you put it on. You can also just use Chrome's built-in breakpoints. These will persist until you disable or remove them, and it doesn't involve modifying any code.
Use Workspaces to map the network path (e.g. a server running locally or externally) to a folder on the file system. Instead of adding the whole app folder, you could select a particular nested folder. This will then appear in the Filesystem section within the Sources tab. You can easily jump to the file at this point. This is one I came up with just now so not fully tested.
I don't have a great example of this, but below I have mapped the css folder.
In the Filesystem section, I see all the files in use from within that folder, not the whole source tree.
If you add the below special comment to line 1 of your JavaScript file, then press Ctrl + P to search for it and open it up, it will effectively be pinned in the sources tab until you close it. Even if you close DevTools, or restart your computer, or update the javascript file, it will persist.
//# sourceURL=myJavaScriptFile.js
Note: If you add a space after the slashes like this '// # sourceURL=myJavaScriptFile.js' it will not work. - I fell into that trap before.
When I upload any changes in javascript files to my deployed site on Google cloud compute engine, the changes do not show up right away, if I load the js files in browser. The changes are physically there, validated by RDPing to the server. B
These changes sometime take 6 to 8 hours to show up in browser, and sometimes show up sporadically. What can I do to ensure that my changed js files take effect immediately on load?
I dont face this problem when I upload on my test server, which is not under cloud. Happens only on the google cloud server.
Try opening your builtin browser debugger (for example right-click on your page, if using Chrome, and click "Inspect"). Now select the Network tab. Now reload. Now look at the sizes of the files. If they are very small, then probably the browser loaded cached copies. You can verify this by checking the "Disable cache" option in the Inspector.
If it works correctly and the file updates right away when you have the browser cache disabled, then you need to investigate with your web server software to see how to cause it to invalidate caches. One mechanism you can look into is called "ETags."
What worked was invalidating the cloud cache for the file. Lesson learnt: always add version numbers to your js files.
I see this strange behavior (or may be I am missing something).
I have WebSphere 8.5. Deployed a EAR. Its working fine.
Instead of repacking and deploying every time for small change, I just copy the js and CSS files directly to the Websphere exploded folder and overwrite the existing files. I see the changes are getting reflected.
I just updated a JS file and added a couple jQuery functions and copied the file like above. Now when I refresh the page, I see the updated code (which is somewhere in the middle of the file). however the js file is not loading fully in all 3 browsers (IE8, Chrome and FF latest). It's getting cut off in the last 10 lines are so.
The file has 1784 lines. Not sure if there is a size limit on the browser side or WebSphere is tinkering with it or something else is going on. Any idea?
I did check the js file I copied to Exploded WebSphere folder. It has complete code.
Note that the page has a few more JS files (jQuery and other files) in addition to this one.
Edit:
I think WebSphere is keeping the size of the file somewhere (maybe?) and sending only that size every time, unless there is clean deploy or restart (?).
I removed a few lines of updated code. Now the browser loads, exactly that many number of additional lines of code. Once I remove my code completely, it loads the full file. (This is not an issue with the code though).
Is there a caching that I need to clear in WebSphere?
Check this page it Hot deployment and dynamic reloading. In general it says that you may need to restart the application.
Also check, if application reloading is enabled, however I'm not sure if it is relevant for static files.
If reloading of classes is enabled and the polling interval is greater
than zero (0), the application files are reloaded after the
application is updated. For JavaServer Pages (JSP) files in a web
module, a web container reloads JSP files only when the IBM extension
jspReloadingEnabled in the jspAttributes of the ibm-web-ext.xml file
is set to true. You can set jspReloadingEnabled to true when editing
your web module's extended deployment descriptors in an assembly tool.
You can restart app from console as provided in comments or via wsadmin script.
I'm trying to fix a tricky JavaScript issue in a Liferay portlet (that also happens to run a large Flex app) and every time I make a change, I have to go back to the prompt and do an "ant deploy" on the portlet, then wait for it to deploy, then reload the page, then wait for the Flex app to load. Every time I try any minor change it takes 3-4 minutes for this whole process.
Is there a configuration or setting that will uncompress the JavaScript and allow me to directly edit the JS files on the server without re-deploying every time? I've read up some on "Developer Mode" but it doesn't seem to be working, and all the Liferay docs seem specific to Tomcat whereas I'm using JBoss.
If you are deploying a war file, just explode it in place (in the jboss deploy directory), so rather than having one compressed file called FlexPort.war, you would have a directory called FlexPort.war which would have all the exploded content from the original WAR file.
If you update JavaScript files, you might need to clear your cache in the browser, but otherwise it should take effect right away. If you update classes, you can cause a fast re-deploy by touch-ing the WAR/web-inf/web.xml file.
===========================================================
Not sure why you're not seeing the JS update, but try reproducing this sequence. It helps to have some browser tool like Firebug or Fiddler installed so you can see the response headers.
Retrieve the JS file directly into your browser. e.g. http://localhost:8080/js/admin/jquery-ui-1.8.12.custom.min.js
Make note of the Last-Modified response header.
Modify the JS file and save. (Make sure the filesystem timestamp of the file has changed)
Retrieve the JS file again. The Last-Modified response header should be incremented to the same value as the timestamp as the filesystem timestamp.
Make sure the HTTP response code is 200 and not 304 (Not Modified).
If you are still seeing the same timestamp after the file modification:
It could be browser caching (See 304 comment above)
I suppose Liferay might be caching all the content, so changes on the file system will not take effect until you redeploy the WAR. If this is the case, try *touch*ing the myportlet.war/WEB-INF/web.xml file which will cause the WAR to be redeployed. Not as efficient, but hopefully faster than reissuing the ant command.
A quickie google revealed this link about Liferay Static Content Caching. It seems Liferay may indeed be caching all this stuff in ehcache. If this is the case with your portlet app, you have 2 choices:
Turn off caching (in dev only, of course) by setting this property in your portal-ext.properties: com.liferay.portal.servlet.filters.cache.CacheFilter=false
If Liferay registers the JMX interfaces for ehcache, you may be able to surgically remove the target items from cache through JMX-Console or twiddle. With either one, once you figure out the exact operation, you can create a batch file to execute it on demand on the command line.
Exploding the war file didn't work out for me. I get around this problem by using a node.js script(an http static file server). What I do is when editing the JS I copy this script to the javascript folder inside the portlet project and fire up the server(You need to install node.js on your dev machine). Then I change the references of my JS scripts in the portlet to point to static server urls.
Eg:- In your liferay-portlet.xml,
<footer-portlet-javascript>/js/app.js</footer-portlet-javascript>
Changes to,
<footer-portlet-javascript>http://localhost:8888/app.js</footer-portlet-javascript>
After that I can just edit the files and view changes in the browser right away.
(You also have to set Access-Control-Allow-Origin header in the static file server)