I'm seeing error messages about a file, min.map, being not found:
GET jQuery's jquery-1.10.2.min.map is triggering a 404 (Not Found)
Screenshot
Where is this coming from?
If Chrome DevTools is reporting a 404 for a .map file (maybe jquery-1.10.2.min.map, jquery.min.map or jquery-2.0.3.min.map, but can happen with anything) first thing to know is this is only requested when using the DevTools.
Your users will not be hitting this 404.
Now you can fix this or disable the sourcemap functionality.
Fix: get the files
Next, it's an easy fix. Head to http://jquery.com/download/ and click the Download the map file link for your version, and you'll want the uncompressed file downloaded as well.
Having the map file in place allows you do debug your minified jQuery via the original sources, which will save a lot of time and frustration if you don't like dealing with variable names like a and c.
More about sourcemaps here: An Introduction to JavaScript Source Maps
Dodge: disable sourcemaps
Instead of getting the files, you can alternatively disable JavaScript source maps completely for now, in your settings. This is a fine choice if you never plan on debugging JavaScript on this page.
Use the cog icon in the bottom right of the DevTools, to open settings, then:
You can remove the 404 by removing the line
//# sourceMappingURL=jquery-1.10.2.min.map
from the top part of your jQuery file.
The top part of the jQuery file will look like this.
/*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license
//# sourceMappingURL=jquery-1.10.2.min.map
*/
Just change that to
/*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license */
Purpose of a source map
Basically it's a way to map a combined/minified file back to an unbuilt state. When you build for production, along with minifying and combining your JavaScript files, you generate a source map which holds information about your original files. When you query a certain line and column number in your generated JavaScript you can do a lookup in the source map which returns the original location. Developer tools (currently WebKit nightly builds, Google Chrome, or Firefox 23+) can parse the source map automatically and make it appear as though you're running unminified and uncombined files.
(Read more on this here)
As announced at jQuery 1.11 and 2.1 Released, the source map comment will be removed so the issue will not appear in newer versions of jQuery.
Here is the official announcement:
One of the changes we’ve made in this beta is to remove the sourcemap
comment. Sourcemaps have proven to be a very problematic and puzzling
thing to developers, generating scores of confused questions on forums
like StackOverflow and causing users to think jQuery itself was
broken.
Anyway, if you need to use a source map, it still be available:
We’ll still be generating and distributing sourcemaps, but you will
need to add the appropriate sourcemap comment at the end of the
minified file if the browser does not support manually associating map
files (currently, none do). If you generate your own jQuery file using
the custom build process, the sourcemap comment will be present in the
minified file and the map is generated; you can either leave it in and
use sourcemaps or edit it out and ignore the map file entirely.
Here you can find more details about the changes.
Here you can find confirmation that with the jQuery 1.11.0/2.1.0 Released the source-map comment in the minified file is removed.
Download the map file and the uncompressed version of jQuery.
Put them with the minified version:
Include minified version into your HTML:
Check in Google Chrome:
Read Introduction to JavaScript Source Maps
Get familiar with Debugging JavaScript
The new versions of jQuery require this file http://code.jquery.com/jquery-1.10.2.min.map
The usability of this file is described here http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
Update:
jQuery 1.11.0/2.1.0
// sourceMappingURL comment is not included in the compressed file.
If you want to get source map file different version, you can use this link
http://code.jquery.com/jquery-x.xx.x.min.map
Instead x.xx.x put your version number.
Note: Some links, which you get on this method, may be broken :)
As I understand the browser, Chrome at least, it doesn't disable the source mapping by default. That means your application's users will trigger this source-mapping request by default.
You can remove the source mapping by deleting the //# sourceMappingURL=jquery.min.map from your JavaScript file.
After following the instructions in the other answers, I needed to strip the version from the map file for this to work for me.
Example: Rename
jquery-1.9.1.min.map
to
jquery.min.map
I was presented with the same issue. The cause for me was Grunt concatenating my JavaScript file.
I was using a ;\n as a separator which caused the path to the source map to 404.
So dev tools was looking for jquery.min.map; instead of jquery.min.map.
I know that isn't the answer to the original question, but I am sure there are others out there with a similar Grunt configuration.
jQuery 1.11.0/2.1.0 the // sourceMappingURL comment is not included in the compressed file.
Assuming you've checked the file is actually present on the server, this could also be caused by your web server restricting which file types are served:
In Apache this could be done with with the <FilesMatch> directive or a RewriteRule if you're using mod_rewrite.
In IIS you'd need to look to the Web.config file.
Related
I have Pandoc 2.2.3.2 installed on my system via Anaconda. The Reveal.js slideshows I convert with it do not work, because the inserted links to the Reveal.js code seem to be wrong. The documentation states that the default URL should be 'https://unpkg.com/reveal.js#^4/'. However, in my generated slides they turn out as in for example <script src="reveal.js/js/reveal.js"></script>, so the base part of the URL seems to be missing.
Fixing the URL by setting the revealjs-url variable is unfortunately not enough, because the files seem to be located under 'dist' rather than the various prefixes 'js', 'css' that I find in my document now.
Where could this be configured in Pandoc? I have searched the documentation and grepped for possible configuration files on my hard drive, with no luck so far.
You should be able to fix this by using an URL pointing to a reveal.js 3.* version. The versioning issue has been fixed in newer versions (pandoc 2.10 and later). Instead of always using the latest reveal.js version, pandoc now pins a specific version.
See this pandoc issue for more details.
I am currently trying to analyse Bugzilla in order to find the ratio of number of bugs : lines of code for each Firefox component. However, I have never worked with Bugzilla before and have no knowledge of Firefox's codebase.
How would I go about finding lines of code per Firefox component (as they appear on Bugzilla under Comp header)? I have made an attempt at looking through mozilla central, but have no idea which source files relate to which components.
EDIT: Dexter pointed out that there is a directive BUG_COMPONENT in the mozilla-central tree, but this directive seems extremely incomplete and is not helpful. Any other advice, or pointers as to where I could get such advice would be much appreciated.
Great question! We recently added the BUG_COMPONENT directive (see the meta bug) to the Firefox code: it's in the moz.build file contained in each directory in the source. This directive allows linking each file in the repository to the related Bugzilla component.
For example, the following directive found here, tells that all the files in test/browser containing the Telemetry word belong to the Toolkit::Telemetry component on Bugzilla.
with Files("test/browser/*Telemetry*"):
BUG_COMPONENT = ("Toolkit", "Telemetry")
You can use either DXR or searchfox to quickly search the Firefox repository.
Updated the answer to account for the questions in the comments.
As noted in the comments, some components are tracked on Bugzilla (e.g. Activity Stream) but do not have a direct mapping to source files within the mozilla-central repository (the one Firefox is built from). That's because some newer components do not ride "the trains" (~6 weeks development cycle), but are rather updated more frequently and deployed as addons.
The code for these components usually lives under the Mozilla github account, along with other project. Since there are quite a number of projects, one way to identify the ones you might be interested in is to restrict them to JavaScript ones. If you follow this last link, you'll see the repository for both the test-pilot and Activity Stream (plus other addons).
I'm afraid the only way to match GitHub projects to Bugzilla components is to look at the name of the repository on GitHub and find the matching component in Bugzilla: you can type the name here to get some component suggestions. If you want to get fancy, you might also leverage the Bugzilla REST API:
Get a list of the JS GitHub project.
Extract the name of the project.
Use the REST API to get the component suggestion.
I would personally just consider the mozilla-central repository as a starting point, as it is mostly annotated: scrape the BUG_COMPONENT from the source files, map them to the paths then use the REST API to get the list of bugs.
Sidenote: the Download Panel seems to be correctly annotated in the main repo.
In some of the bootstrap example templates they include the following code:
<!-- Just for debugging purposes. Don't actually copy these 2 lines! -->
<!--[if lt IE 9]><script src="../../assets/js/ie8-responsive-file-warning.js"></script><![endif]-->
Does this mean that those lines should not actually be included in final site builds? I've searched several development sites where people are asking about including bootstrap in their designs and most responses cut and paste from the bootstrap examples including those lines. So just trying to figure out if they should be removed when building an actual site.
Thanks.
Does this mean that those lines should not actually be included in final site builds?
Yes, you should exclude those lines. Otherwise, I wouldn't have added that explanatory HTML comment in the first place.
All ie8-responsive-file-warning.js does is show an error message to developers trying to use file:// URLs with IE8. It isn't useful in production code.
Likewise, ie-emulation-modes-warning.js just shows an error message to developers trying to ill-advisedly use IE's unreliable emulation modes feature. Again, not useful in production.
The lines will make a warning appear for users with IE 8 or older. If that's what you want, leave them in.
I'm having trouble with an XSL translation in Chrome. I was wondering if there any tools that would allow me to step through the style sheet to see where the problem is.
Use node tests to check the results of XPath queries.
Use the document function to test file paths
Use the JavaScript console to run XPath queries on the XML data source
Use inline templates instead of xsl:include to eliminate path issues
Use comments to eliminate xsl:include statements referencing buggy templates
Use processing-instructions to comment blocks of code that have XML comments
Use an embedded stylesheet to workaround same-origin policy restrictions
Use input tags to print xsl:variable values.
Use attribute value templates to print unknown values
Use simplified stylesheets and parameterized XPath to modularize templates
Use Opera as a cross-reference, since it shows line numbers in its XSLT error messages.
On linux there is a tool called xsltproc which takes an XSL and XML and outputs the transform.
It also shows context around errors.
I've found this most useful when I'm developing as I can test the result of my changes without the need to have a development server up and running. It just works.
However, I've noticed that the results of the transform can differ from that of Chrome for example. I don't know why this is, whether my transform was non-conforming, if Chrome is non-conforming, or if xsltproc is non-conforming.
EDIT My comment about differences between Chrome and xsltproc rendering the transform slightly differently is likely invalid.
I had modified the XML schema somewhat, and since then, xsltproc was generating tags (based on type name of types in the schema) correctly, but Chrome was not.
I was doing hard reloads to avoid Chrome reusing the cache.
I could tell Chrome was using the new xsl as there was other changes included that were being rendered.
Only the schema related tests were not working in Chrome for some reason.
I've since found that now it is magically working, with no changes to the xsl, just on a different day.
So I guess some part of the xsl was being cached somehow (perhaps just the schema bit - totally guessing here)... hence why some debugging in Chrome would be super nice.
I'm writing a web-crawler using Chickenfoot and need to save PDF files. I can either click the link on the page or grab the PDF's URL and use
go("http://www.whatever.com/file.pdf")
and I get the firefox "Opening file.pdf" dialog box, but can't click the "OK" button to actually save the file.
I've tried using other means to download the files (wget, python's urllib2, twill), but the PDF files are gated so none of those will work.
Any help is appreciated.
This example of how to save a target in the Mozilla developer documents looks like it should do exactly what you want. I've tested a Chickenfoot example that is very similar that gets the temp environment variable, and that worked well for me in Chickenfoot.
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIWebBrowserPersist#Example
You might have to play with the application associations in Tools, Options, Applications to make sure the action is set to Save File, but those settings might not apply to these functions.
End Answer, begin related grumblings...
I sure wish someone would fix the many bugs in Chickenfoot, and write a nice Cookbook programming guide. I've been using it for years, and there are still many basic things I've not been able to figure out how to do. I finally broke down and subscribed to the mailing list, as the archives have some decent script examples. It takes a lot of searching through the pdf references, blogs, etc. as the web API reference is very sparse.
I love how simple Chickenfoot can make automating some tasks, but it takes me days of searching javascript, DOM, and Firefox documents to find ways to do some of the things it can't, since I'm not really a web programmer. The goal of Chickenfoot seems to be that I shouldn't have to be, but unfortunately few are refining the proof of concept, as MIT has dropped the project.
I tried to do this several ways using only Chickenfoot commands and confirmed they don't work with the latest Firefox 3 and Chickenfoot 1.0.7.
I hope this helps! Good luck. Sorry I only ran across your question yesterday, but found it too interesting to leave alone.
You won't be able to click on Firefox dialogs for the sake of security.
The best way to download the content of a URL is to read then write the content of the URL.
// Chickenfoot 1.0.7 Javascript Code to download the content of a url.
include( "fileio.js" ); // enables the write function.
var url = "http://google.com",
saveFileTo = "c://chickenfoot-google.com";
write( saveFileTo, read( url ) );
You might find it helpful to use jquery with chickenfoot.
http://groups.csail.mit.edu/uid/chickenfoot/scripts/index.php?title=Using_jQuery,_jQuery_UI_and_similar_libraries
This has worked for me to save Excel files from NCES portal.
http://muaz-khan.blogspot.com/2012/10/save-files-on-disk-using-javascript-or.html
I was using Firefox 3.0 and the "old syntax" version of the code. I also stripped code intended for IE and "(window.URL || window.webkitURL).revokeObjectURL(save.href);" which generated an error.