I'm facing some weird issues with gulp-sourcemaps and gulp-uglify working together, basically, we use the gulp-uglify to minify our code and gulp-sourcemaps to create the source map of the project to be debugged the JS code at the console.
So today, while debugging I noticed Google Chrome seemed to was executing an if statement even I knew the condition didn't retrieve a true value, I had my if like this if ('string-A' === 'string-B') { image.onerror = null } So, I added a breakpoint at the onerror assignment and chrome was pausing my code there. A very weird case.
I started debugging so I changed the source code for the minified file, to check if the minified code was causing the issue, this is the block of code minified:
l === i && i !== t ? o ? a.src = n : e(a) : l === n ? e(a) : l === t && (a.onerror = null)
I don't see any issues there, I checked with some new breakpoints, and highlighted piece of code is never executed because l === t retrives false as it should do. Then I used again the source file just to verify that the onerror value never changed for the image as I thought, so it seems to be an error with the Chrome core while trying to match the minified file with the source. It seems that Chrome stops at a random place.
Is there a way to avoid these issues? I ask this because it took us a long time to test and actually the output is the same, we just validated it was not an issue in our side.
In my case, we had some comments were not removed before from the source code, so It was the reason source and the minified file was not matching.
Related
I have a Vue application and I'm trying to debug it in Chrome DevTools. The problem is when I try to find the file I want to debug, I get a list of files with the same name plus some weird hash tacked onto the end:
When I open any one file, I get some garbled minified code:
Sometimes I can find the file I want (with the original source code) but sometimes not.
What are these weird files and how can I find the file I want (with the original source code). Is there a way of getting the DevTools to list only the original source code files?
Thanks.
What tool in dev tools are you using to get that list? Seems like a list of cached files, so it's showing all the old versions of your code.
If you go to the network tab and reload the page. You should see a list of all the resources downloaded by the browser. Choose the js filter and you should see your vue js bundle (made by webpack) somewhere in that list.
To allow chrome to display the source correctly you need to generate the Source Maps in development deployments.
I am not sure what tool you are using to build and bundle, but it is likely that you might have support for this already.
Chrome Details:
https://developer.chrome.com/docs/devtools/javascript/source-maps/
OMG - debugging my debugging environment. It's SO maddening.
I'm working with Vue v2, and I'm using vuetify in my app. Here is a complete vue.config.js configuration that solved this problem for me.
// vue.config.js file
const path = require('path')
const { defineConfig } = require('#vue/cli-service')
module.exports = defineConfig({
transpileDependencies: [
'vuetify'
],
configureWebpack: config => {
if (process.env.NODE_ENV === 'development') {
// See available sourcemaps:
// https://webpack.js.org/configuration/devtool/#devtool
config.devtool = 'eval-source-map'
// console.log(`NOTICE: vue.config.js directive: ${config.devtool}`)
config.output.devtoolModuleFilenameTemplate = info => {
let resPath = path.normalize(info.resourcePath)
let isVue = resPath.match(/\.vue$/)
let isGenerated = info.allLoaders
let generated = `webpack-generated:///${resPath}?${info.hash}`
let vuesource = `vue-source:///${resPath}`
return isVue && isGenerated ? generated : vuesource
}
config.output.devtoolFallbackModuleFilenameTemplate =
'webpack:///[resource-path]?[hash]'
}
},
})
I found a work around for this. While you can not see the source code of your file, just change the code (add console or sth.) of the file you want to see while Vue is hot reloading your changes. It occurs to me that the source code is then reachable when you check the developer console.
There is a surprising number of developers I meet on projects that have no idea there are official browser extensions for debugging Vue, Router, VueX etc.
Stumbling across this question prompted me to post this life saving link for those that land here and have missed the existence of this essential tool:
https://devtools.vuejs.org/guide/installation.html
CefSharp: 1.25.0 (based on Chromium 25.0.1364.152)
Angular: 1.3.0-beta16
UIRouter: 0.2.10
I'm developing a stand-alone C# application that uses CefSharp Chromium + Angular + UIRouter as the stack upon which the GUI will be relying on.
I hit it off by trying to make the above stack load the sample-code provided here:
http://scotch.io/tutorials/javascript/angular-routing-using-ui-router
For the sake of elegance the HTML + Javascript-libs of the GUI, get cobundled in a single resource file inside the .Net executable of the application.
This resource is then passed programmatically during application-init to the Chromium control (by means of .LoadHtml) to be loaded directly into the browser, aka the HTML is not loaded from a separate .html file residing in the hard-drive or on a remote HTTP server. If the HTML gets loaded from the later ("standard") venues then everything works flawlessly.
I noticed that when loading the HTML directly as a string, as described above, the url of the resulting static web page (aka window.location) is set to 'about:blank'. It appears that angular has some sort of pet peeve with such a url, especially when it comes to using routing:
First of all, the invocation of:
history.pushState(null, "", url);
inside
self.url = function(url, replace) { ... }
throws an exception ala
Error: SecurityError: DOM Exception 18
Error: An attempt was made to break through the security policy of the user agent.
at Browser.self.url (about:blank:8004:21)
at about:blank:10049:24
at Scope.$eval (about:blank:11472:28)
at Scope.$digest (about:blank:11381:31)
at Scope.$apply (about:blank:11493:24)
at about:blank:6818:15
at Object.invoke (about:blank:7814:19)
at doBootstrap (about:blank:6817:16)
at bootstrap (about:blank:6827:14)
at angularInit (about:blank:6796:7)
the url that is passed to .pushState is:
about:blank#/home
which appears to be the result of concatenating 'about:blank' with the default state '/home'.
Secondly, even if the above problem is solved there appears to be a major issue inside:
$rootScope.$watch(function $locationWatch() { ... })
which causes the following error:
Error: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!
the reason is that when 'window.location' is set to 'about:blank' then
$browser.url()
always returns
about:blank
while
$location.absUrl()
returns
about:blank#/home
causing $watch to fire non-stop.
Is there any proper way to handle this shortcoming of angular when its dealing with web pages loaded directly into the browser in the manner described here?
If there is no workaround for this issue then I'm afraid that I will have to resort to loading the HTML directly from a file in the hard drive, which apart from being slower (can't cache the string to memory for subsequent usages), it's also a noticable deviation from the goal of developing a stand-alone-exe. :(
Thanks in advance and I apologize if this issue has been addressed elsewhere.
By default Firefox allows loading of external files within html file that loaded from "file:///...". but Chrome does not. in CefSharp(Chrome) you can do it in this way:
// Allow angular routing and load external files
BrowserSettings setting = new BrowserSettings();
setting.FileAccessFromFileUrls = CefState.Enabled;
browser.BrowserSettings = setting;
this.Controls.Add(browser);
Most browsers don't allow to do AJAX on the file-system. But Chromium can be tweaked to do so:
browser = new ChromiumWebBrowser(path);
browser.BrowserSettings = new BrowserSettings();
browser.BrowserSettings.FileAccessFromFileUrlsAllowed = true;
Recently I read a query about "What does console.log do" and I read an answer, tried using it and found that despite the answer stating that it outputs to the console in googles browser, I just tried it and I get no output.
I did try this code:
function put(p){
if ( window.console && window.console.log ) {
console.log(p); // console is available
}else{
alert(p);
}
}
BUT... I get neither console output or alert and furthermore .log is a Math property, what gives with that?
Make sure that in the Developer Tools the Filter in the console section is set to All or Logs...
I had a similar experience where I couldn't see any of my console.log output and it was because the console was set to filter on Errors only... All the log entries were there - they just weren't visible.
Bonus marks: you can also Ctrl + Click to select multiple filters (Errors + Logs for example).
Press F12 and look at in Developer Tools: Console. I tried your code just now, works fine for me -- Chrome version 30.0.
Since you're after console logging, not mathematical logarithms, perhaps you could stop going on about there being similarly-named function in the Math object. It's not relevant here whatsoever.
You're also coming across just a little shouty. console.log() works fine, and your question didn't indicate that you knew where to look. This is totally your problem, but I'm trying to help you. I can obviously only go on the information you provide, and I can't say your initial question was written very clearly.
It appears, since the snippet of code you posted works here absolutely fine, that your calling code & containing (which you haven't posted) would be the cause of the problem. You should debug these, to find out what's going wrong.
Do you know how to use the Chrome debugger? Are there any error messages showing in Chrome or on the console?
Test it on a simple page if necessary, to rule out other errors in the page/ or surrounding context breaking it. One common mistakes is declare functions in a jQuery ready handler or similar, and then try & access them globally. Make sure your logging function is actually global (outside any other function(){} or object {} blocks).
Lastly, it's good to have a logging function for portability (I have one myself) but put() is not a good name for it. Naming it consoleLog() or log() would be better.
Had the same issue .
Make sure your using de right path when you try import thing's .
Example whit my issue :
Wrong path ----> ** import normalizedData from 'normalizr'; **
Right path ---> ** import normalizedData from '../schemas/index.js'; **
I had also faced the same problem. Make sure you apply no filter in the console. It worked for me.
I am trying to use the "Result of Script" Requirement to check if a particular process is running, so that I can message the user before installation begins.
My script is a shell script that returns 1 for failure and 0 for success. The problem I'm having is that, regardless of my return value, the installer flow is interpreting it as failure. I am not using an incredibly simple script:
#!/bin/bash
echo "script starting">> /tmp/myfile
true
(the echo is to assure myself that the script is, in fact, running). I've tried replacing the last line with a lot of things (exit 0, exit 1, "true", "TRUE") but nothing results in the test passing.
I also discovered the following JavaScript code that gets added to distribution.dist when I activate this requirement.
<installation-check script="pm_install_check();"/>
<script>function pm_install_check() {
if(!(system.run('path/to/script/myscript.sh') == true)) {
my.result.title = 'Title';
my.result.message = 'Message';
my.result.type = 'Fatal';
return false;
}
return true;
}
</script>
as far as i can tell, the expression in the if statement will never evaluate to true. So, I'm assuming this is my problem. I don't know how to get around it, though, because this code is generated by PackageMaker.
Update
I've decided to work under the impression that this is a bug in PackageMaker, and am close to a workaround. Rather than using the "Result of Script" requirement, I used the "Result of Javascript" requirement, and built a Javascript function the looks like
function my_check() {
code = system.run('path/to/script/myscript.sh');
return code == 0;
}
Now my only problem is that this will only work when I point to my script via an absolute path. Obviously this poses a problem for an installer.
It's probably too late for you but I feel like this should be documented somewhere.
I'd been looking around for an answer for this for most of this morning. Long story short I ended up looking at generic bash scripting and I found some info about returning values from a script called by a script. Here's how it can be done:
Anywhere you'd be using exit 0 (for success) use $(exit 1).
As you'd expect exit 1 should be replaced by $(exit 0).
I realize that it's backwards and I don't really get the reasoning behind it but after some experimentation that's what I found.
Well, this isn't exactly an answer to the question, but it did end up being a solution to my problem. This freeware packaging utility called Packages supports the "Result of Script" functionality and handles the path correctly. Unfortunately the packages it creates are only compatible with OS 10.5 and later. To support 10.4, I'm building a separate installer using PackageMaker but skipping the "Result of Script" requirement.
I've downloaded the examples for both the Request and Request.HTML and cannot make either work. I unzipped them to a folder and browsed to their index.html to execute them as is, but the response is always "The request failed." with no clues as to why.
I've played around with them with different permutations and can get the request to complete but it always fails. Is there any way to get a reason for failure? I've tried three different browsers turned off my firewall, used relative and absolute file references but nothing works. Am I missing something glarringly obvious? I'd post the code, but it is the examples exactly as is...
Any help would be awesome.
Cheers,
Justin.
If I'm remembering correctly, AJAX requests in most browsers cannot be done via the local file system - you'll need an actual web server like Apache going. In Windows, XAMPP will get you up and running with Apache in minutes.
Most any webserver should work. It's just that your filesystem doesn't "respond" to browser requests the way a web server does:
ajax requests that are executed
locally (against the file system)
don't work well because the ajax logic
is looking for a state change and a
server response, neither of which are
provided by your file system
-- http://forum.mootools.net/viewtopic.php?id=5009
The XMLHttpRequest object can handle more than just HTTP requests supposedly, but at least in mootools, it's not meant to. And "file:///..." is not an HTTP request. It's just taking a file from your file system and displaying it in the browser.
So the good news is: any web browser, including even a bare-bones one running on your local machine, should work fine :)
Brilliant!! Thanks very much! I uploaded it to my nearest webserver and sure enough it works.
I did try doing some Ajax calls directly from my filesystem without any javascript libraries - using XMLHttpRequest() - and it worked fine, so this does seem like a strange limitation. Can I be sure this will always work from any webserver, however basic? It's just that this project I'm working on is going to be using multiple hosting environments, mainly just plain HTML type sites for the client enviornments of which I'll have no control... Is there a minimum specification?
Cheers ;)
The XMLHttpRequest() succeeds cause there's nothing wrong with making the local call. it's just different and the problem is in the buggy mootools isSuccess function.
You gotta override it the Request options. Here's how jquery does it
// Determines if an XMLHttpRequest was successful or not
httpSuccess: function( xhr ) {
try {
// IE error sometimes returns 1223 when it should be 204 so treat it as success, see #1450
return !xhr.status && location.protocol === "file:" ||
// Opera returns 0 when status is 304
( xhr.status >= 200 && xhr.status < 300 ) ||
xhr.status === 304 || xhr.status === 1223 || xhr.status === 0;
} catch(e) {}
return false;
},