We Keep Coding

webkitspeechrecognition no longer prompts for permission

I've been prototyping a few pages that use webkitspeechrecognition. I learned quickly that you cannot load these from a file, you have to serve them from a webserver. I'm using osx so I just moved my files to the local apache that was already running and enabled. This worked fine for quite a while.
For some reason, none of my pages that were working fine will prompt me to deny/allow the microphone usage. I even copied an existing working page from another webserver and if I load it from http://localhost/speech.html it will not prompt. It skips the prompt and goes to my recognition.onerror handler and logs "not-allowed"
However, if I load the same page (or any of my other prototypes) from http://127.0.0.1/speech.html it works fine. This made me think I had accidentally cached a response like "always deny" or something. I think I cleared/reset all my chrome settings but I'm still getting the same behavior. 127.0.0.1 will properly prompt, but localhost will not prompt at all.
Where might chrome be storing some additional settings that I need to clear?

Your microphone settings might be stored at chrome://settings/contentExceptions#media-stream-mic. You can view the websites that have permissions saved there.

getUserMedia permissions requesting in chrome currently works something like:
If you have a request by http, getUserMedia will only remember the permissions for that session. If you go back to the same page. it asks again.
If you do the same request by https, once you set the permissions, you always have permissions.
My memory is that an exception is granted for http://localhost/... for debugging purposes. In this case, you don't need to repeatedly grant
permissions.
If you use http and 127.0.0.1/, I think no exception is made.
http://www.html5rocks.com/en/tutorials/getusermedia/intro/

Chrome blocking iframe requests as cross-origin request even when origins are the same

This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.

I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.

Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.

Replace remote JavaScript file with a local debugging copy using Greasemonkey or userscript

While debugging a client app that uses a Google backend, I have added some debugging versions of the functions and inserted them using the Chrome Developer Tools script editor.
However there are a number of limitations with this approach, first is that the editor doesn't seem to always work with de-minified files, and when the JS file is 35K lines long, this is a problem.
Another issue is that all the initialization that is done during load time, uses the original "unpatched" functions, hence this is not ideal.
I would like to replace the remote javascript.js file with my own local copy, presumably using some regex on the file name, or whatever strategy was suitable, I am happy to use either Firefox or Chrome, if one was easier than the other.

So basically, as #BrockAdams identified, there are a couple of solutions to these types of problem depending on the requirements, and they follow either 1 of 2 methods.
the browser API switcharoo.
The proxy based interception befiddlement.
the browser API switcharoo.
Both firefox and chrome support browser extensions that can take advantage of platform specific APIs to register event handlers for "onbeforeload" or "onBeforeRequest" in the case of firefox and chrome respectively. The chrome APIs are currently experimental, hence these tools are likely to be better developed under firefox.
2 tools that definitely do something like what is required are AdBlock plus and Jsdeminifier both of which have the source code available.
The key point for these 2 firefox apps is that they intercept the web request before the browser gets its hands on it and operate on the other side of the http/https encrpytion stage, hence can see the decrypted response, however as identified in the other post that they don't do the whole thing, although the jsdeminifier was very useful, I didn't find a firefox plugin to do exactly what I wanted, but I can see from those previous plugins, that it is possible with both firefox and chrome. Though they don't actually do the trick as required.
The proxy based interception befiddlement This is definitely the better option in a plain HTTP environment, there are whole bunch of proxies such as pivoxy, fiddler2, Charles Web HTTP proxy, and presumably some that I didn't look at specifically such as snort that support filtering of some sort.
The simplest solution for myself was foxyproxy and privoxy on firefox, and configure a user.action and user.filter to detect the url of the page, and then to apply a filter which swapped out the original src tag, for my own one.
The https case. proxy vs plugin
When the request is https the proxy can't see the request url or the response body, so it can't do the cool swapping stuff. However there is one option available for those who like to mess with their browser. And that is the man-in-the-middle SSL proxy. The Charles Web HTTP proxy appears to be the main solution to this problem. Basically the way it works is that when your browser makes a request to the remote HTTPS server, the ssl proxy intercepts the request and from the ip address of the server generates a server certificate on the fly, which it signs with its own root CA, and sends back to the browser. The browser obviously complains about the self-signed cert, but here you can choose to install the ssl proxy root CA cert into the browser, befuddling the browser and allowing the ssl proxy to man in the middle and make replacements and filters on the raw response body.
Alternative roll your own chrome extension
I decided to go with rolling my own chrome extension, which I am planning to make available. Currently its in a very hardcoded to my own requirements state, but it works pretty good, even for https requests and another benefit is that a browser plugin solution can be more tightly integrated with the browser developer tools.

How to force Chrome/Firefox/Opera to do crossdomain requests from localhost?

Hy,
So I've got this problem: I'm trying to develop an HTML file on my localhost, and all the browsers I have installed are preventing me to send cross-domain requests.
What I'm trying to do is to convert a script I wrote in Python (with Mechanize, pyquery and lxml) to Javascript, the reasons don't really matter (I thought in Javascript it would be easier to simulate something).
Cross-domain requests from local files used to work, and are still working on the latest Safari (stable), but I can't install Safari on this machine (it's a Linux box).
EDIT
I discovered the escalated privileges of Firefox, e.g.:
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
// among others
Problem is, I'm also trying to access the content loaded in an iFrame ... as I said, I'm trying to simulate a browser session, like I would with a library like Mechanize, but from Javascript. My script still works in Safari.
So how to force Chrome / Firefox / Opera to bypass all security restrictions from locally stored files?
I'm interested in a browser command-line option, I would even consider a patch to the browser (I'm the user, not trying to distribute this to anyone else).
Thanks,

I'm unsure whether or not you have control of the content in the IFrames but since you are speaking of local files I guess you do. This article on Ajaxian should cover your use case.
Since you are targeting grade A browsers (e.i. not IE) you could use html5 window.postMessage instead of IFrames.
Cheers, Jon.
I have no working knowledge of Python Mechanize lib.

Why don't you start a simple http server instead to solve your problem?
import sys
import BaseHTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
HandlerClass = SimpleHTTPRequestHandler
ServerClass = BaseHTTPServer.HTTPServer
Protocol = "HTTP/1.0"
if sys.argv[1:]:
port = int(sys.argv[1])
else:
port = 8000
server_address = ('127.0.0.1', port)
HandlerClass.protocol_version = Protocol
httpd = ServerClass(server_address, HandlerClass)
sa = httpd.socket.getsockname()
print "Serving HTTP on", sa[0], "port", sa[1], "..."
httpd.serve_forever()
This python code will start a simple http server listening on port 8000 or the first argument and handles all files in the folder from this script.

I'm not sure if this works when the page is on localhost, but it might be worth a try: http://www.asual.com/jquery/address/
That jQuery plugin lets you make cross-domain requests from any domain... Perhaps it might work with localhost? Haven't tested it though.

Very strange JavaScript error in IE7

I am developing JavaScript chat. I have done the prototype, and it seems to work pretty well. But our client says that it doesn't work. We both use IE7 on PC, and try to run the same JavaScript code. I have no idea about the reason.
On my client's machine there is "object is expected" error. I have thought about security restrictions, and tried to make security level higher in my IE, but in this case the script doesn't run and there is no error messages. I am running the script on the remote server.

Clients machine may be running within a group policy which for security reasons can restrict execution of scripts. Hence the client may need to include your prototype as part of their trusted sites and relax restrictions on trusted sites
Are you able to provide any more details about the specific error? Are you sending the client a zipped up version of the solution or is it hosted somewhere?

From the IEBlog; you could try using the Microsoft Script Debugger (see post)
One thing you may find, especially with IE is the error that is reported is actually caused by a previous error in the code.
Try running your javascript through jslint to ensure that it is well formed.
In Firefox with [firebug], enable strict warnings in the console.
Related SO posts.
debugging-javascript-in-ie7.
debugging-javascript-for-ie6.
Edit::
One thing to look for is comma's after the last element in an array, IE seems to ignore the closing brace } and keep adding following code to the array. Firefox gracefully just assumes that you forgot it.

If you're running the code from localhost and he's running it from a remote server then it could be a timing issue - some script could be running before the page has finished loading that's causing a problem on a slow connection that is hidden on a fast connection.

You can get this error if you try to use an exernal script file that the client's browser can not access.
Example :
<script src="http://localhost/scripts/freelib.js" language=Javascript> </script>
You can access freelib.js on your machine, but running it from any other machine it wouldn't work.

Are you sure all the scripts are being loaded? I've seen that error message before when some or all aren't loaded (maybe they didn't get deployed). Try manually copying the addresses of all the js files from the source and pasting them into the address bar to make sure that the browser can actually access them.
Can you run the page on your client's machine in Firefox? The firefox console should give you a more detailed error message than IE will.