User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20100401 Firefox/3.6.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20100401 Firefox/3.6.3 When using FF with proxy configured, FLASH requests are still handled directly. Reproducible: Always Steps to Reproduce: 1. Make sure you have Adobe Flash plugin installed 2. Make sure your machine cannot access Internet without a proxy. 3. Configure FF t use a Socks proxy. 4. Open any site that uses a Flash applet for file upload, say http://imageshack.us/ 5. Try to upload an file. Please note, that system (in my case - Internet Explorer) proxy configuration is used. Actual Results: A system window prompting for proxy password with current Windows user pops up. Expected Results: FF routes all webpage traffic through FF's proxy configuraion. The situation is the same with over flash applications which access the Internet, like streaming video or secure authentication.
Here's the screenshot http://yfrog.com/jdclipboard1ij
This is a "bug" or limitation in the flash plugin and not Gecko/Firefox.
Yeah, I understand that. But hopefully Mozilla is big enough now to finaly make Adobe patch this bug?
Gecko supports proxy for plugins with bug 470993
Reproduced: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0 Mozilla/5.0 (X11; Linux i686; rv:12.0a2) Gecko/20120311 Firefox/12.0a2 Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120311 Firefox/13.0a1 Adobe Flash Player 184.108.40.206
i'm not able to reproduce the issue you are describing with imageshack.us. i've tried 2 different types of proxies, a local ssh tunnel and ccproxy remotely deployed on another win machine, both not requiring a username or password. with firefox pointed to the local machine and remote socks server respectively, my request to upload an image on imageshack uploaded to completion without a prompt. btw, i don't see anywhere to set a username or password in either windows default or firefox's socks setting...
You're doing it wrong. To redproduce the issue, you must have a Windows machine with Intenet Explorer settings configured to use a HTTP proxy, requiring a login and password. In a Windows Active Directory domain and IIS Server, that is typically the same L/P used to login into the domain. Then, in FF, select a socks proxy for network connection. I.e., globally system is configured to use one proxy (http in IE), but FF is configured to use another one (socks proxy). Flash in FF will be using the global configuration, not the FF one. Sorry can't provide more details or screenshots, as I reported this ages ago and I don't have access to that particular environment anymore.
On a second thought, perhaps you could just specify a non-existent proxy of any type in IE, making sure IE can't connect to the internet no matter what. Then specify a working proxy in FF and try that imageshack proxy thing. I'm trying to say that Flash in FF uses system network settings prior to FF.
Hm, looks like not all flash ignores the proxy settings. I didn't test with http://imageshack.us/ specifically in comment 6. Further testing shows that some flash content breaks out of the proxy and some content doesn't, but I haven't found out what makes the difference.
Are you sure you have a clean experiment? Perhaps you still have direct internet connection, and you just set up a localhost proxy? Try limiting the internet connectiong to that only proxy on another machine in the same net. As of comment 3, this is perhaps the NPSWF32.dll bug. But I still would like FF to incapsulate those plugins somehow, so thay won't do what they want. There're little ways to route traffic on windows, and specifying proxy for FF is one of the most effective ways to do that.
i see what you mean now. i set a bogus http proxy and now the upload fails. if the http proxy is set, requests are attempted first through the system http proxy rather than going through the specified socks proxy server. i'm asking around why this is the case.
I'm closing a lot of bugs which are filed as Adobe Flash bugs which are either irrelevant, not actionable, or not serious enough to track in the Mozilla bug tracker. For the most part, Flash bugs should be filed in Adobe bugbase, and we'll only track a few highly-critical issues in the Mozilla tracker.