I'm debugging a XUL-based Firefox extension which has been broken by Firefox 46 release.
When I run the extension, the Browser console shows:
Invalid chrome URI: /
with neither line numbers nor stack trace.
On Web forums, I've read that ChromeBug could be used for that. Then, I've tried the latest stable version of ChromeBug (1.7.2) but it hasn't been updated since oct. 2014, and seems to be incompatible with recent Firefox versions.
Because the extension is an "old-style" one, I cannot use the Add-on debugger, therefore I used the Browser toolbox, but it doesn't display the exception.
Considering the number of lines of the extension, wandering around in the code is not an option. Any idea how I could get a stack trace?
When getting this type of error in the Browser Console where you are given very little information as to what is causing the error it is likely that the error is not in JavaScript, and probably not even inside your code. In such cases, it is impossible to obtain a JavaScript stack trace because it just doesn't exist.
Such a thing is usually caused by issues in XUL or HTML used in a popup or tab that is opened. Your add-on opens a tab with the contents of chrome://restclient/content/restclient.html. Substituting for that file an HTML document with no content makes the error go away.
Using a binary search of the contents of that file (comment-out/delete progressive half portions of the file at a time and test to see if the errors still exist) to A) confirm that the error is there and B) what is causing the error, results in determining that the following line is causing the error to show up in the Browser Console (line 197):
<input class="span5" style="width:-moz-calc(100% - 1em) !important;" type="password" name="password" autocomplete="on" placeholder="Password">
A little more testing shows that the problem goes away when type is not password. Copying the original HTML document to a place where I can access it easily with a file: URL, results in no such error in the browser console when the document is opened.
Thus, the conclusion is that it is a bug in Mozilla's code for <input type="password"> when loaded from a chrome: URI.
Finding an invalid chrome: URI in code without a stack trace:
If the problem was not found in the HTML or XUL files, it would be necessary to look through the chrome: URIs which are used in your add-on to find what might be the cause.
chrome: URIs have some properties we can take advantage of in tracking down such an issue:
chrome: URIs are usually static.
chrome: URIs usually come in the format chrome:\\packageName\{content,skin,locale}
Your chrome.manifest file defines what chrome: URIs can be valid for your add-on/package.
Other chrome.manifest files define what chrome: URIs can be valid outside of your add-on/package.
So first look at your chrome.manifest file:
content restclient content/
resource restclient ./
overlay chrome://browser/content/browser.xul chrome://restclient/content/overlay.xul
overlay chrome://navigator/content/navigator.xul chrome://restclient/content/overlay.xul
style chrome://global/content/customizeToolbar.xul chrome://restclient/content/css/overlay.css
This tells us that in your package, the only valid internal chrome: URIs will be in the format chrome://restclient/content/ and will refer to the content directory within the root directory of your add-on.
So, we now look for all the chrome: URIs used in your add-on. To do that, the command line of grep -nri chrome: * is an easy way to do so. grep is available as a standard utility program under multiple operating systems. In Windows, I usually get it from Cygwin. From that command we get:
chrome.manifest:4:overlay chrome://browser/content/browser.xul chrome://restclient/content/overlay.xul
chrome.manifest:5:overlay chrome://navigator/content/navigator.xul chrome://restclient/content/overlay.xul
chrome.manifest:6:style chrome://global/content/customizeToolbar.xul chrome://restclient/content/css/overlay.css
content/css/overlay.css:30: list-style-image: url("chrome://restclient/content/images/icon16.png") !important;
content/css/overlay.css:33: list-style-image: url("chrome://restclient/content/images/icon16.png") !important;
content/js/restclient.js:51: i18nStrings = new restclient.StringBundle("chrome://restclient/locale/restclient.properties");
content/js/restclient.main.js:1040: xslDocument.load("chrome://restclient/content/xsl/XMLPrettyPrint.xsl");
content/js/restclient.main.js:1053: xslDoc.load("chrome://restclient/content/xsl/XMLIndent.xsl");*/
content/js/restclient.overlay.js:68: browser.selectedTab = browser.addTab("chrome://restclient/content/restclient.html");
content/overlay.xul:2:<?xml-stylesheet href="chrome://restclient/content/css/overlay.css" type="text/css"?>
content/overlay.xul:7: <script type="application/x-javascript" src="chrome://restclient/content/js/restclient.js" />
content/overlay.xul:8: <script type="application/x-javascript" src="chrome://restclient/content/js/restclient.overlay.js" />
content/overlay.xul:23: image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:35: image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:46: image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:58: image="chrome://restclient/content/images/icon16.png"/>
modules/StringBundle.js:59: * new StringBundle("chrome://example/locale/strings.properties");
Now, we could, and probably should, look through that manually for problems, but we can shorten the list quickly to find obvious problems with the command: grep -nri chrome: * | grep -v chrome://restclient/content/. This will give us any chrome: URIs which are not in the format for references to your add-on's content. The list obtained could easily contain valid chrome: URIs that reference files outside of your add-on. So, we might need to do more checking. From the above command we get:
content/js/restclient.js:51: i18nStrings = new restclient.StringBundle("chrome://restclient/locale/restclient.properties");
modules/StringBundle.js:59: * new StringBundle("chrome://example/locale/strings.properties");
The first is a locale chrome: URI. You do not specify a locale in your chrome.manifest. It is, therefore, certainly invalid. Looking at line 51 of content/js/restclient.js it is in active code. When it actually gets used, it will be invalid.
The second possibility is a typical example chrome: URI. The line begins with a * hinting that it might be a comment. Checking line 59 of modules/StringBundle.js shows that it is a comment.
The next step, if the problem had not already been found, would be to resolve the known invalid chrome: URI(s) and test to see if that solved the problem. In this instance, we already know what the problem is, so there is no need to check.
However, given that the chrome://restclient/locale/restclient.properties is invalid and A) there is no such file in your add-on and B) no locale defined in your chrome.manifest it means that if that code was executed it would fail. Basically it appears that function, restclient.i18n, is dead/bad code and should be removed. Given that function is the only use of the modules/StringBundle.js file, it could be removed also. Obviously, if this is something you are actively working on then that is a different story.
In working on this, I also noted a couple of other errors in the Browser Console which you should probably take a look at:
21:26:37.975 SyntaxError: test for equality (==) mistyped as assignment (=)?1 chrome://restclient/content/js/bootstrap.js:1557:33
21:26:37.989 TypeError: variable url redeclares argument1 chrome://restclient/content/js/restclient.main.js:376:8
While these are not inherently errors, it is generally desirable to not have anything show up in the Browser Console during the normal operation of your add-on. Although, given the various errors reported in jquery.js what are a couple more?
Related
The site works fine on Chrome/iOS/Safari/Android (you should be able to select and image and proceed to write a message on the next step). Firefox refuses to run my project's main script (you can't select an image or go forward), and gives the following error in the console:
> Content Security Policy: Directive ‘frame-src’ has been deprecated.
> Please use directive ‘child-src’ instead. (3) Unknown
It's very cryptic. I've tried the following:
1) Adding a meta tag for the CSP in the header.
Result: Creates more errors if restrictive, same amount of errors if
left to wildcards on all parameters.
2) Locally serving all scripts.
Result: I still get three unknown CSP errors. It also loads a lot
slower since the dependencies are not being loaded from a CDN.
3) Removing specific scripts.
Result: It reduces the errors by up to one, but it seems all scripts
are equally responsible. Very strange behavior.
Is this a bug in Firefox that is unsolvable? I'm tearing my hair out over this.
I needed to put listeners in $(document).ready as Firefox loads things differently as pointed out to me by Matt Gibson.
Content Security Policy did not cause the script to fail. However, it is a weird error message that gives you no information to where the error is originating, and can potentially break the site, but that is not what happened here.
I have written a Firefox Extension using Web Extension APIs. It has passed the Preliminary review but the reviewer said that he cannot proceed with the full review cause when he installs it, he gets the following error -
"Unable to parse JSON data for extension storage"
Upon inspecting for quite sometime, I figured that Firefox creates a file called "storage.js" in the profile folder for each extension where it writes and reads from, all the local storage data for that particular extension. And if the extension tries to write to this file before this file is created, the error "Unable to write JSON data to extension storage" is thrown and if the extension code tries to read from this file before this file is created, the error "Unable to parse JSON data for extension storage" is thrown.
Now, my concern is how do I know for sure that the file has been created and that it can be written to or read from?
PS : This happens when the extension is just installed. For consequent sessions, this error wont come as that file is no longer missing.
This seems to be a bug in the current Firefox implementation, and your assessment is spot on:
The underlying ExtStorage module will always call read before get, set etc. even write and clear.
read will unconditionally try to access the underlying, extension specific storage file, that may not exist yet for freshly installed add-ons using the storage API for the first time.
This will therefore result in the logging of one such Unable to parse JSON data for extension storage message, no matter what you do with the storage API.
Therefore triggering the message cannot be avoided.
I suggest you do the following:
Contact the editors team, requesting they re-evaluate your add-on based on:
The message in question is really only a warning (when appearing after first access of the storage API by your addon).
Even when the message would be an actual error (the storage is corrupt), it would still not be your error, as the storage API implementation by mozilla needs to be more resilient then and there is nothing you can do anyway.
The message being issued on first regular use of the storage API, unrelated to what WebExtensions add-on uses that API and in what way, is a mozilla bug, and not something you caused or can fix yourself or at least work around.
Therefore denying a full review just because a mozilla bug erroneously logs a spurious message once without any other severe effects is... questionable.
File a bug about this so mozilla developers can address this issue. You'll wanna CC at least Bill McCloskey (:billm) since he wrote that code ;)
I have just upgraded from kendoui.web.2013.1.514 to kendoui.web.2013.2.716 and have noticed that in the parts of the code where I require (through require.js) a certain kendo.culture.xx-XX.min.js file that also an unsuccessful request for kendo.core.min.js happens and I get an error in the console.
This did not happen with kendoui.web.2013.1.514 and I think this part inside the kendo.culture.xx-XX.min.js files might be to blame:
("function"==typeof define&&define.amd?define:function(e,n){return n()})(["../kendo.core.min"]
Also this reference to kendo.core appears to only be present in the minified versions. Note that I already have kendo.web.min.js fully loaded and the app works fine even with the invalid request so is this a bug?
If you are using the bundles (i.e. kendo.web.min.js) then you shouldn't use RequireJS to load them or any culture files.
I'm sorry that the documentation didn't mention it, I just added a section to explain this.
I'm working on a custom module that will describe an external table to the Views module. Inside my module folder I have the required mymodule.views.inc file. However, whenever this file is present and my custom module is enabled Drupal constantly gives Ajax HTTP Error pop ups when I use a site feature that has Ajax (any of the spinning daisies trigger this). The pop up always contains the module code in mymodule.views.inc after it says Ajax Error. The weird thing is every time I load the front page the PHP code in mymodule.views.inc is always displayed on the top of the front page.
I've seen this problem on SO and other sites a lot, but most of the time it can be traced back to an updated jquery.js file or a php.ini setting that will give scripts more time to run. So far neither of those fixes have worked. The only way I can make it go away for now is to either disable my custom module, or rename mymodule.views.inc to something else.
Here's an example of what the message looks like (not verbatim copy, since I can't copy from these alert messages in Chrome).
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /?q=admin/structure/views/view/viewiamtryingtocreate/preview/page/ajax
StatusText: parseerror
ResponseText: /*
* header file to my mymodule.views.inc
* file I wrote
*/
//more php code follows
//lots of unicode characters intermittently show up in my source code
\u003C\/div\u003E\n...
//source code continues with lots of unicode characters, not sure what's at the bottom because the alert box is bigger than my screen and I can't scroll on it
Does anyone else know what could be going on?
This error is caused by drupalforfirebug, disabling drupal for firebug should help. or else this patch should work.
Found it. Syntax error hiding at the top of mymodule.views.inc. There was some weird formatting before the opening PHP tag. Not sure why php --syntax-check mymodule.php didn't catch it (I copied mymodule.views.inc to mymodule.php so that I could run the syntax checker on it).
On my production ASP.NET MVC 3 site, I've been noticing the occasional "A potentially dangerous Request.Path value was detected from the client (%)." unhandled exception in the Windows application log.
While these can be perfectly valid under regular site usage (ie/ random web bots), a number of the requests appear to be from valid, local ISP users.
In the exception's request details, the Request URL is different than the Request path:
Request URL: http://www.somesite.com/Images/Image With Space.jpg
Request path: /Images/Imagehttp://www.somesite.com/Images/Image With Space.jpgWithhttp://www.somesite.com/Images/Image With Space.jpgSpace.jpg
Notice that in the "request path", any place there is a "space" in the path is replaced with an exact copy of the request url!
Within the site, the actual link looks like this:
<img src="/Images/Image%20With%20Space.jpg" />
Any idea what might be causing this? I tried to look at the documentation for Request.Path and Request.Url, but I can't figure out why they would be different. Hitting the Request URL directly brings up the resource correctly.
Update: I managed to get a trace of one of the malfunctioning requests by using IIS 7.0's Failed Request Tracing feature:
Referer: Google search
User-Agent: Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
RequestURL: http://www.somesite.com:80/Images/Image%20With%20Space.jpg
Typing the URL manually into my iOS 5.1.1 brings up the image correctly. Searching for the image in Google Images brings up the image correctly. Still no successful reproduction.
Partway down the trace I see:
MODULE_SET_RESPONSE_ERROR_STATUS Warning. ModuleName="RequestFilteringModule", Notification="BEGIN_REQUEST", HttpStatus="404", HttpReason="Not Found", HttpSubStatus="11",
According to IIS' documentation, 404.11 from the Request Filtering module is a "double encoding" error in the URL. Experimenting a bit, if I purposefully create a double encoded url such as http://www.somesite.com/Images/Image%2520With%2520Space.jpg I get the exact error in the event log, complete with malformed Request Path.
The malformed Request Path in the event log error appears to be a bug in ASP.NET 4.0.
It doesn't, however, explain why I'm getting the error in the first place. I checked a large number of failed request logs - the only common factor is that they're all using AppleWebKit. Could it be a bug in Safari?
The httpRuntime section of the Web.Config can be modified to adjust the URL validation. ASP MVC projects are usually running in the validation mode 2.0 and the default invalid characters (separated by commas) are listed below.
<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="<,>,*,%,:,&,\" />
As you can see the % sign is considered invalid. A space can be encoded to %20 causing the validation error. You can just add the requestPathInvalidCharacters attribute to the httpRuntime section in your Web.Config file and copy the values I listed below except for the "%," part.
Scott Hanselman has a blog post about this issue:
http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx
I can't help thinking that - given the restricted user-agent - this might represent incorrect handling of the URL by that browser on IOS 5.1.1. I don't personally own such a device so I can't test this - but it would be interesting to investigate how it behaves with a url that actually has spaces in it instead.
I have a feeling that it's seeing the %20 in the url from the page source and double-encoding it, thinking it's being helpful. The problem there being that IIS will decode it back (before ASP.net kicks in) and throw it's rattle out of it's pram because now it sees a literal %20 instead of a space.
I personally don't recommend modifying your servers' security settings; however it would be the easiest solution so I dare say that's what you will do.
Rather, I think if you can confirm this 'bug' (I'm already on the road, finding a safe hiding place from Apple's lawyers), find a format that works for this device; or take all the spaces out of your resource urls. A - is the best alternative.