In the credits section of Chromium and Chrome (chrome://credits/) you can find XUL Runner SDK.
I've done some search in the chromium website and didn't find any sign of it nor for what is it used.
I was trying to decide between using something like chromiumembedded, Awesomium, WebKit, XUL Runner, libRocket, etc. so that finding is confusing.
So my question is: Why is XUL Runner SDK in chrome://credits/ ?
You should search the source code to check. The only actual use of the XULRunner SDK appears to be in mock_ie_event_sink_test.h where an accessibility-related file is being included. Constants from that file (like IA2_EVENT_DOCUMENT_LOAD_COMPLETE) are then being used in mock_ie_event_sink_test.cc - a unit test file. So the dependency on XULRunner doesn't seem to apply to any code actually shipping with Google Chrome.
Related
I just installed Chrome Dev Editor and gave it a try with one of the sample templates:
New Project >> Project Type = JavaScript Chrome App (using Polymer paper elements) >> Create
Right-click >> Refactor for CSP
Click on Run (black arrow)
A window opens with what seems to be the sample Polymer app, without Polymer features (only html markup). Here is what the Console reports in Developer Tools:
extensions::platformApp:31 Uncaught Error: document.write() is not available in packaged apps.
index.html:338 GET chrome-extension://fonts.googleapis.com/css?family=RobotoDraft:regular,bold,italic,thin,light,bolditalic,black,medium&lang=en net::ERR_FAILED
core-resizable.html.0.js:95 Uncaught TypeError: undefined is not a function
polymer.html.0.js:5 Uncaught TypeError: Cannot read property 'parentNode' of undefined
unresolved.js:30 Uncaught ReferenceError: Platform is not defined
queue.js:138 Uncaught ReferenceError: CustomElements is not defined
I find it quite surprising that sample apps bundled with the IDE do not work out of the box, so I guess I must be doing something wrong somewhere...
My question is : does anyone know what changes i should make to the sample code or to my configuration to have it run properly?
Thanks
Note: might be useful, I'm using Chrome Version 39.0.2171.71 m
TL;DR
To fix, just update your Chrome Dev Editor and make sure it's at version 0.18.3465 in the About dialog (to update, just relaunch the app the app: that should be sufficient). 0.18.3465 is a hot fix I've just pushed to the Chrome Web Store.
Details
The immediate problem was triggered by the bleeding edge Polymer sources that very recently broke compatibility with Chrome Apps in a few places.
On the other hand, Chrome Dev Editor 0.18 was supposed to pin down the Polymer version used in the templates to the latest stable release, denoted as ...#latest in all Polymer package specifications inside the bower.json of a generated project. However, it contained a bug that sometimes (just after a fresh installation) generated bower.json's pointing at the bleeding edge Polymer, denoted as ...#master. So the above-mentioned hot fix was just fixing that bug.
Just to be sure, you could look in the bower.json of a newly generated project and see what's in there. If the problem persists, please file a bug at https://github.com/dart-lang/chromedeveditor/issues/new.
I have a big Selenium test suite that's testing a web service. Given an input url, the web service returns either a regular html response or a json response. The test suite is being executed with Firefox's Selenium IDE. The tests call the open command on a given url and then verify stuff on the returned json/html. It used to work great until for some reason Firefox has stopped opening the jsons automatically. Instead of opening the json response as if it were a regular web page, Firefox asks "What should Firefox do with this file" and prompts me to select a program to open the file with.
How do I force Selenium IDE to make Firefox display the json responses as it used to?
Cases like these are usually Firefox & Selenium IDE version incompatibility. This can be from using a much newer version or an old version of Firefox that the IDE doesn't quite support.
In your case it appears to be an older version issue.
The first step you should do is update both the IDE & Firefox and take it from there.
The release notes also detail what version (range) of Firefox it generally supports.
I'm trying to get TypeScript source debugging working in Chrome, but I'm running into two specific and perhaps related problems.
The first is that the comment generated by the TypeScript/WebEssentials compiler that's supposed to identify the location of the source map file looks like this:
//sourceMappingUrl=MySourceFile.js.map
But Chrome won't read that file. It seems expect that the comment will look like this:
//# sourceMappingUrl=MySourceFile.js.map
If I manually change the comment to that, and refresh my page, then magically the references to all the .ts files show up as sources in the Chrome Developer Tools.
However, that leads to my second problem, as the files don't actually get loaded. The .ts source file that Chrome should be trying to download is http://localhost/MySourceFile.ts, but the one that it's actually trying to download is http://localhost/C:/source/web/MySourceFile.ts. That sort of makes sense, as the opening attributes of MySourceFile.js.map look like this:
{"version":3,"file":"tmp1523.tmp","sources":["C:/source/web/MySourceFile.ts"
But that obviously doesn't work with Chrome, as it interprets the source-map location to be entirely relative, and IIS (quite correctly) won't serve up any URL looking like http://localhost/C:/source/web/MySourceFile.ts.
So, with respect to these two problems, is it Chrome or the TypeScript source-map feature that's doing it wrong? And what's the recommended way of doing this?
I'm using Chrome 25.0.1323.1 dev-m, with TypeScript 0.8.1 and WebEssentials 1.8.5.
This is an issue with version 1.8.5 of Web Essentials (the version currently available from the Visual Studio Gallery). The latest nightly build (at time of writing http://madskristensen.net/custom/webessentials2012.vsix) fixes the problem and generates the map linkage correctly.
We are trying to distribute a basic HTML file with some links to a PDF document in a USB drive for advertising purposes. The idea is that an autorun opens up this HTML in the default browser. However, this might not be a good idea since it would look very amateur-ish and we will have to rely on the default browser's technology (which unfortunately has a good chance on being IE6/7!)
We've explored a few alternatives, but we can't find one that really fits what we are trying to achieve:
Mozilla Prism
Altough it seems like it's designed with offline web apps in mind, the executable creates files in the user's AppData directory and it's hard to configure the default paths. Also, Firefox doesn't have a default PDF viewer, so we will have to depend on the user's default PDF viewer (which might be Adobe Reader)
Mozilla Chromeless
Since Prism is inactive, the idea is still developing with Chromeless, which allows the developer to create the browser interface with basic HTML/JS/CSS. The main issue here is that somehow the build isn't loading HTML, all that's showing is a gray iframe. I'm not sure if it's just me, because there's nothing on the issues page.
Portable App
We could throw in the portable version of Firefox or Chrome and customize the XUL for Firefox or open Chrome in app mode.
Firefox's advantage is that it kind of supports relative paths (resource://), but it doesn't have a built-in PDF viewer. Chrome has a very good and lightweight PDF viewer and the built-in app mode is a very useful feature for us, but I can't find how to open a local path without the usual absolute path (file:///C:/) since we don't know what's the drive's letter.
Has anyone figure out how to handle this kind of issues? Thanks.
This has been asked three years ago, but it's unanswered, listed high in Google, and I stumbled over the exact same problem and can imagine that many others that seek to ship portable web apps that can be run locally and with a minimum of dependencies will encounter this issue, too.
The solution I am now going with is the node-webkit.
You can treat it like a portable version of chrome, however it excepts a relative path to your app's entry point, is about 40 MB smaller, and much more customizable than the --app mode of chrome (which isn't customizable at all if I remember correctly).
Github & Download:
https://github.com/rogerwang/node-webkit#downloads
An extensive guide:
http://thejackalofjavascript.com/getting-started-with-node-webkit-apps/
My usage suggestion for Windows:
First create an app package as explained in the guide linked above
For the node-wekit to load with your app, you need to start it like this:
nw.exe app.package
Where nw.exe is in the root of the zipped folder you downloaded and app.package is a zip file (can have any name) that contains your app data and package.json.
To do this silently, you can use a BAT file containing the (amended) call above and a VBS file containing something like this:
CreateObject("Wscript.Shell").Run "cmd /c launchNW.bat", 0, true
launchNW.bat being the name of your BAT file. Now run the VBS file; a window containing your web app should pop up without the command window appearing with it.
Finish reading the linked guide to learn more about customization options to do things like hiding the browser UI etc.
Does Google provide non-minified / non-obfuscated versions of their various javascript API's?
For example, I'm using their LocalSearch control and getting a cryptic error "a is null". Setting a breakpoint in Firebug is not very helpful because I'm 3 levels deep in minified code.
There isn't a non-obfuscated version of the API (it isn't an open source project). If you post a link to the page in question, we might be able to help debug the issue?
I have seen the "a is null" message many times and each time have been able to track down the issue eventually.
As mentioned, there isn't a way to get the original version with real (helpful) variable and comments since it's not open source
But! There's a new(ish?) feature in Google Chrome Dev Tools where you can de-minify code ("make minified code human readable")
https://developers.google.com/web/tools/chrome-devtools/javascript/reference#format
should at least help a bit with debugging