window_handles request on real ios device

[Sergio Neves Barros]

Guys,

I am trying to grab the window_handles on the WebViewApp and this is working fine on a iphone simulator however it's throwing an unhandled exception on a real device (I tried on iphone 5 and Ipad 3).

I am using the appium app Version 1.5.1 (but I found the same when pulling appium from git and running node server.js)


########################## Device Iphone 5 with appium app ########################################
debug: Appium request initiated at /wd/hub/session/014e5b84-5081-4084-8813-863e1c982ca5/window_handles

error: uncaughtException date=Wed Apr 10 2013 17:19:54 GMT+0100 (BST), pid=64736, uid=2134065780, gid=1519764623, cwd=/Applications/Appium.app/Contents/Resources/node_modules/appium, execPath=/Applications/Appium.app/Contents/Resources/node/bin/node, version=v0.10.3, argv=[/Applications/Appium.app/Contents/Resources/node/bin/node, /Applications/Appium.app/Contents/Resources/node_modules/appium/server.js, --address, 127.0.0.1, --port, 4723, --app, io.appium.WebViewApp, --udid, 3d166189e591575bbfc562e9643c03dee1f4bbfd, --keep-artifacts, --verbose, --without-delay], rss=31518720, heapTotal=19654912, heapUsed=13020008, loadavg=[2.4384765625, 2.53271484375, 2.49365234375], uptime=203109, trace=[column=11, file=net.js, function=errnoException, line=878, method=null, native=false, column=19, file=[as oncomplete] (net.js, function=Object.afterConnect, line=869, method=afterConnect, native=false], stack=[Error: connect ECONNREFUSED,     at errnoException (net.js:878:11),     at Object.afterConnect [as oncomplete] (net.js:869:19)]

##############################################################################################


########################## Simulator Iphone with appium app ########################################
debug: Appium request initiated at /wd/hub/session/4fef1665-3d96-453b-9ce8-4d49bb71c83b/window_handles

info: [REMOTE] Debugger socket connected to ::1:27753
info: [REMOTE] Sending connection key

debug: [REMOTE] Sending _rpc_reportIdentifier: message to remote debugger
debug: [REMOTE] { __argument: { WIRConnectionIdentifierKey: '9b8f05bf-8df9-4998-ba88-655e55588463' },
  __selector: '_rpc_reportIdentifier:' }

debug: [REMOTE] Receiving data from remote debugger

info: [REMOTE] Selecting app

debug: [REMOTE] { __selector: '_rpc_reportSetup:',
  __argument:
   { WIRSimulatorNameKey: 'iPhone Simulator',
     WIRSimulatorBuildKey: '10B141' } }
debug: [REMOTE] Sim name: iPhone Simulator
debug: [REMOTE] Sim build: 10B141
debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] { __selector: '_rpc_reportConnectedApplicationList:',
  __argument:
   { WIRApplicationDictionaryKey:
      { 'io.appium.WebViewApp':
         { WIRApplicationIdentifierKey: 'io.appium.WebViewApp',
           WIRApplicationNameKey: 'WebViewApp',
           WIRIsApplicationProxyKey: false } } } }
debug: [REMOTE] Sending _rpc_forwardGetListing: message to remote debugger
debug: [REMOTE] { __argument:
   { WIRConnectionIdentifierKey: '9b8f05bf-8df9-4998-ba88-655e55588463',
     WIRApplicationIdentifierKey: 'io.appium.WebViewApp' },
  __selector: '_rpc_forwardGetListing:' }

info: Responding to client with success: {"status":0,"value":["1"],"sessionId":"4fef1665-3d96-453b-9ce8-4d49bb71c83b"}
GET /wd/hub/session/4fef1665-3d96-453b-9ce8-4d49bb71c83b/window_handles 200 370ms - 98

debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] { __selector: '_rpc_applicationSentListing:',
  __argument:
   { WIRApplicationIdentifierKey: 'io.appium.WebViewApp',
     WIRListingKey:
      { '1':
         { WIRPageIdentifierKey: 1,
           WIRTitleKey: 'I am a page title - Sauce Labs',
           WIRURLKey: 'http://saucelabs.com/test/guinea-pig' } } } }
debug: Appium request initiated at /wd/hub/session/4fef1665-3d96-453b-9ce8-4d49bb71c83b/window
debug: Request received with params: {"name":"1"}
debug: [REMOTE] Sending _rpc_forwardSocketSetup: message to remote debugger
debug: [REMOTE] { __argument:
   { WIRApplicationIdentifierKey: 'io.appium.WebViewApp',
     WIRConnectionIdentifierKey: '9b8f05bf-8df9-4998-ba88-655e55588463',
     WIRSenderKey: '29213f2a-fbb0-4a2b-a84e-c431d591a51f',
     WIRPageIdentifierKey: 1 },
  __selector: '_rpc_forwardSocketSetup:' }
debug: [REMOTE] Sending _rpc_forwardSocketData: message to remote debugger
debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] <applicationSentData response>
debug: [REMOTE] Sending _rpc_forwardSocketData: message to remote debugger
debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] Receiving data from remote debugger
debug: [REMOTE] <applicationSentData response>
debug: [REMOTE] Page loading

info: [REMOTE] Selecting page 1 and forwarding socket setup
info: [REMOTE] Set sender key
info: [REMOTE] Enabled activity on page
info: [REMOTE] Sending javascript command
info: [REMOTE] Checked document readystate
info: Responding to client with success: {"status":0,"value":"","sessionId":"4fef1665-3d96-453b-9ce8-4d49bb71c83b"}
POST /wd/hub/session/4fef1665-3d96-453b-9ce8-4d49bb71c83b/window 200 11ms - 87
info: Responding to client with success: {"status":0,"value":"","sessionId":"4fef1665-3d96-453b-9ce8-4d49bb71c83b"}
POST /wd/hub/session/4fef1665-3d96-453b-9ce8-4d49bb71c83b/execute 200 2ms - 87
info: Shutting down appium session...
info: [REMOTE] Disconnecting from remote debugger
info: [REMOTE] Debugger socket disconnected
##############################################################################################

Any ideas on what could be happening?

Sergio

[Jonathan Lipps]

This is unfortunately expected. Webview support works by creating a TCP connection to the remote webkit debugger run in Safari/webviews. Even though the real device might be running a webkit debugger, it's almost definitely not forwarding that port to the host, where appium is running.

Someone will need to figure out how to reverse engineer the USB debugging protocol and forward the port from the device to the host---sounds like it will be challenging at best and maybe impossible at worst.

--
http://appium.io
---
You received this message because you are subscribed to the Google Groups "Appium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to appium-discus...@googlegroups.com.
Visit this group at http://groups.google.com/group/appium-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Sergio Neves Barros]

http://oodlestechnologies.com/blogs/Data-transfer-to-iOS-devices-from-PC-using-USB-cable--(using-USB-Multiplex-Daemon)

Something like this? I'll have chat with some of the guys in my office to see if we can have a look at this.

Thanks,

Sergio

[Jonathan Lipps]

That looks tantalizing! The port to forward would be 22753, on ipv6 ::1

[Sergio Neves Barros]

google seems to have already set something up for this using usbmuxd:
https://github.com/google/ios-webkit-debug-proxy

We're trying to get this up and running now.

Sergio

[Jonathan Lipps]

That looks really promising. If you can get a proof of concept working, we can incorporate it into appium more tightly. Or, just have people run this and use port 27753 so that appium picks it up automatically.

[Sergio Neves Barros]

Jonathan,

We have been able to install/launch the ios webkit debug proxy from google:

You pull it from git and navigate into the src folder and then run:

brew install ios-webkit-debug-proxy

Once installed you launch it with the following command:

ios_webkit_debug_proxy -c :22752-22758

This will assign the ports as follows:
22752 - to list attached devices (http://127.0.0.1:22752)
22753 - associated with the first attached device. (http://127.0.0.1:22753/json)

However when running with appium as previously described I still get the same error.
Who initiates the request on port 22753 (appium or the device). I would assume the appium, and if that is the case this should work.

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

Appium uses IPv6 to connect to port 22753 on ::1. Does ios-webkit-debug-proxy use IPv6?

[Sergio Neves Barros]

Jonathan,

It seems that the ios-webkit-debug-proxy(e.g. usbmuxd) only supports IPv4.

gl2654m:~ sergio.barros$ telnet localhost 22753

Trying ::1...

telnet: connect to address ::1: Connection refused

Trying 127.0.0.1...

Connected to localhost.

Would it be possible to change appium to support IPv4 as well? (Pretty please :))

Sergio

[Jonathan Lipps]

What we'd need to do is branch on ipv4 vs ipv6 based on whether we have a real device (signified by this.udid in ios.js--this would need to be passed to remote-debugger.js so it can do the branching at the point it starts the tcp connection). So if we don't have a real device, use ::1, otherwise use 127.0.0.1. Can you try a proof of concept in your fork? It'd be a valuable pull request and I'm happy to help along the way--maybe better to track progress on github.

On Apr 11, 2013, at 9:40 AM, Sergio Neves Barros <s.neve...@googlemail.com> wrote:

[Sergio Neves Barros]

Jonathan,

Happy to do this. I changed the remote-debugger.js file locally and was able to establish a connection. 

However upon first request (get window_handles) usbmuxd kicks the bucket:

gl2654m:python-client sergio.barros$ python tcprelay.py -t 27753:27753

Forwarding local port 27753 to remote port 27753

Incoming connection to 27753

Waiting for devices...

Connecting to device <MuxDevice: ID 30 ProdID 0x12a6 Serial '82b6cfb3ca181c17afc8a45b68bbf956a5358f68' Location 0xfd123000>

----------------------------------------

Exception happened during processing of request from ('127.0.0.1', 57828)

Traceback (most recent call last):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 582, in process_request_thread

    self.finish_request(request, client_address)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 323, in finish_request

    self.RequestHandlerClass(request, client_address, self)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 639, in __init__

    self.handle()

  File "tcprelay.py", line 82, in handle

    dsock = mux.connect(dev, self.server.rport)

  File "/Users/sergio.barros/git/usbmuxd/python-client/usbmux.py", line 235, in connect

    return connector.connect(device, port)

  File "/Users/sergio.barros/git/usbmuxd/python-client/usbmux.py", line 206, in connect

    raise MuxError("Connect failed: error %d"%ret)

MuxError: Connect failed: error 3

----------------------------------------

Do you have any idea what request would be coming in on port 57828?

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

Hmm no clue at all about that port! It's almost exactly double 27753 though :-)

[Sergio Neves Barros]

Jonathan,

It's been quite a challenge figuring out the Javascript syntax, as I far more comfortable with Java. 

However I was able to figure out where to get the udid and I comitted the changes on my local fork.

It works and when a real device is attached it uses IPv4 and IPv6 for simulator.

However something goes wrong after sending the connection key. Is there a handshake step I am missing?:

debug: Appium request initiated at /wd/hub/session/d4119296-a49b-4f33-92ca-b3badd543b39/window_handles

info: [REMOTE] Debugger socket connected to 127.0.0.1:27753

info: [REMOTE] Sending connection key

debug: [REMOTE] Sending _rpc_reportIdentifier: message to remote debugger

debug: [REMOTE] { __argument: { WIRConnectionIdentifierKey: 'b155ed40-eed0-4a8d-b5a8-6931d67ac59d' },

  __selector: '_rpc_reportIdentifier:' }

info: [REMOTE] Debugger socket disconnected

info: Pushing command to appium work queue: "au.alertIsPresent()"

debug: Sending command to instruments: au.alertIsPresent()

info: [INSTSERVER] Sending command to instruments: au.alertIsPresent()

info: [INST] 2013-04-13 21:36:02 +0000 Debug: target.setDeviceOrientation("1")

       2013-04-13 21:36:07 +0000 Default: Got new command 2 from instruments: au.alertIsPresent()

info: [INSTSERVER] Socket data received (51 bytes)

info: [INSTSERVER] Socket data being routed for 'cmd' event

info: [INSTSERVER] Got result from instruments: {"status":0,"value":false}

info: Pushing command to appium work queue: "au.alertIsPresent()"

debug: Sending command to instruments: au.alertIsPresent()

info: [INSTSERVER] Sending command to instruments: au.alertIsPresent()

info: [INST] 2013-04-13 21:36:10 +0000 Default: Got new command 3 from instruments: au.alertIsPresent()

info: [INSTSERVER] Socket data received (51 bytes)

info: [INSTSERVER] Socket data being routed for 'cmd' event

info: [INSTSERVER] Got result from instruments: {"status":0,"value":false}

Thanks,

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

Well done on the fix. Unfortunately  have no clue why the debugger socket would disconnect. Does it use exactly the same protocol and encoding as the simulator debugger? I'd assume so.

Does talking to the remote debugger work with other applications (like maybe you could open it in safari dev tools?)

[Sergio Neves Barros]

Two updates:

1. When I use usbmuxd directly to forward 27753 it seems to get additional requests on a random port (which is causing the previously mentioned failure).

 - I would need to understand why this is happening and which port(s) need to be forwarded for this to work.

2. When using ios-webkit-debug-proxy a connection is established (using IPv4) however the window_handles request is made but never gets a response (and is the repeated several times until the connection times out).

 debug: Appium request initiated at /wd/hub/session/3c2bf267-faea-4852-92ed-73fdb391da0d/window_handles

info: [REMOTE] Selecting app

debug: [REMOTE] Sending _rpc_forwardGetListing: message to remote debugger

debug: [REMOTE] { __argument: 

   { WIRConnectionIdentifierKey: 'd1aa4120-9e64-48d9-b84c-4d6db2b708dc',

     WIRApplicationIdentifierKey: 'com.gamesys.Steve' },

  __selector: '_rpc_forwardGetListing:' }

After about 30 seconds the ios-webkit-debug-proxy process showed an error "Invalid HTTP header". I am assuming that when using the proxy some additional/different header is needed which is currently not there.

Any words of wisdom (that can point me in the right direction) as I am struggling here?

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Sergio Neves Barros]

Right, should have gone through documentation a bit more before :).

After re-reading through the diagram for the ios-webkit-debug-proxy I found that the proxy is expecting requests using the WebKit Remote debugging protocol (and then "translates" these to iOS web inspector protocol).

Since appium sends the requests using the web inspector protocol, the proxy couldn't handle them (and was therefore disconnecting).

There are two ways to resolve this one:

1. Update Appium to use the WebKit protocol (however this would affect running tests against the simulator)

2. Update the ios-webkit-debug-proxy to simpy "forward" (web inspector protocol) requests

Feedback? Or am i stark raving mad here ;).

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

I think your research has been fruitful. I was going to say, there's something off about the "Invalid HTTP Header" error, because the iOS protocol is pure TCP. Perhaps it's actually expecting websocket rather than pure TCP. What happens with usbmuxd if you use a port other than 27753? We can use any port since we're already branching for real device vs simulator in remote-debugger now. What if you try something you're sure isn't running on your comp, like :8080 or something like that?

WebKit protocol and iOS protocol aren't that different, I think they're just wrapped differently (iOS converts JSON structures to binary plist to send over the wire). Would take a bit of research but it might not be that hard to update remote-debugger to also use webkit protocol. We'll have to do this for chrome on android eventually anyway.

[Sergio Neves Barros]

I updated the usbmuxd port but no luck.

I have found a description of the webkit debug protol here and am currently updating the remote-debugger.js file to use a socket connection and this protocol.

Once I have got it working  with some of the calls I will commit the changes to my fork as a proof of concept.

I am assuming the simulator would still require the iOS web inspector protocol?

Sergio


On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

Yes, simulator still needs to send the binary plist encoded version of the protocol. In my understanding it is the same protocol as the webkit debug protocol, just a unique way of encoding the data.

[Sergio Neves Barros]

Jonathan,

I have setup the proof of concept and have been able to communicate with a real device through the webkit protocol using the ios-webkit-debug-proxy.

Just install and then start the proxy with the following command "ios_webkit_debug_proxy -c :27752-27754" . Then start the appium server with a real device attached.

The two calls that I have confirmed are "get title" and page refresh.

Done: 

1. Connection established through websocket

2. Page objects retrieved through http://localhost:27753/json file

3. Execute javascript against page (for now only get page title and refresh page).

Todo:

1. Process response properly (as it currently only prints it).

2. Execute atoms (will be looking at this tomorrow with some colleagues).

3. Cleanup etc..

Result:

debug: Appium request initiated at /wd/hub/session/ec2972f9-6747-457e-8eb2-026449f80316/window_handles

info: [REMOTE] Debugger web socket connected to url [ws://localhost:27753/devtools/page/1]

info: Responding to client with success: {"status":0,"value":["1"],"sessionId":"ec2972f9-6747-457e-8eb2-026449f80316"}

GET /wd/hub/session/ec2972f9-6747-457e-8eb2-026449f80316/window_handles 200 12ms - 98

debug: Appium request initiated at /wd/hub/session/ec2972f9-6747-457e-8eb2-026449f80316/window

debug: Request received with params: {"name":"1"}

info: Remote debugger is already connected to window [1]

info: Responding to client with success: {"status":0,"value":"1","sessionId":"ec2972f9-6747-457e-8eb2-026449f80316"}

POST /wd/hub/session/ec2972f9-6747-457e-8eb2-026449f80316/window 200 1ms - 88

debug: Appium request initiated at /wd/hub/session/ec2972f9-6747-457e-8eb2-026449f80316/title

info: [REMOTE] Executing 'title' atom in default context

info: [REMOTE] Remote debugger data sent [{"id":1,"method":"Runtime.evaluate","params":{"objectGroup":"console","includeCommandLineAPI":true,"doNotPauseOnExceptionsAndMuteConsole":true,"expression":"document.title","returnByValue":true}}]

info: [REMOTE] undefined

recv {"result":{"result":{"type":"string","value":"| Jackpotjoy"},"wasThrown":false},"id":1}

Succes! :)

Once the todo's are done I will commit those as well.

Sergio.

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Sergio Neves Barros]

Have done some more digging and it seems that when executing the atoms (e.g. find element) the web socket is disconnected for some reason.
I was able to successfully execute the atom including parameters against the page using firebug, however was unable to run it as an runtime.evaluate expression using the webkit protocol.

This seems to be dependent on the size of the script to be executed. I increased the size of the script with a large comment to around 7500 characters and this caused web socket to disconnected. For smaller requests it worked as expected. Do you know if ws has a max size for it's send function?

Any suggestions?

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

Interesting. I wonder if it's hitting the packet size limit for the protocol. I never ran into any issues locally but maybe using websockets over the wire it breaks? Seems like that should be handled in the websocket client though.

[Sergio Neves Barros]

I have raised a ticket with ios-webkit-debug-proxy project as it seems to be the same when using chrome to connect to the proxy (and executing the script through the console).

Will see if they come back with anything or if there are any C developers in our office that can help.

Thanks,

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[am...@live.com]

Hello,

  We are running into the same issue.  I see that ticket mentioned for ios-webkit-debug-proxy is resolved.  Have you tried  with that fix?  Has this issue been resolved?

thanks

[Sergio Neves Barros]

The issue raised with the ios-webkit-debugging-proxy has been resolved (woohoo) :).

We have been working on getting it running on a real devices (with some success) however with limited javascript experience :(.

When you are using the proxy there are differences:

1. We establish a web socket connection directly with each WebView (rather than a tcp connection).
• the list of web views can be retrieved from the json generated by the proxy.
  
2. The protocol used is the webkit remote debugging protocol (rather than the WebInspector protocol)
• The only real difference between the two is that the Web Inspector protocol has additional parameters and it sends the request as a plist
  

Setup:
1. Pull the latest version of the ios-webkit-debug-proxy and install it. The brew install didn't seem to have the fix, so i ran the following:

  ./autogen.sh
  ./configure       
  make
  sudo make install
2. Start the proxy with this command:
  ios_webkit_debug_proxy -c :27752-27758 -d

3. Start appium with a real device (and put a break point at the "this.socket.send(data) line 512 of the webkit-remote-debugger.js").
 Note: I have a feeling there is a threading/cb issue somewhere as when i let my test run the proxy simply disconnects but if I give it a second it works (we're having a look into this)
4 Run a simple test to switch to the latest window and find an element using id.
5. Eventhough  it states that it has responded with a success, the test doesn't continue and is still waiting!.

Loggging:
debug: Appium request initiated at /wd/hub/session/811f7d7d-b4d3-453c-8338-b14738947912/window_handles
info: [REMOTE] Debugger web socket connected to url [ws://localhost:27753/devtools/page/3]
info: Responding to client with success: {"status":0,"value":["3"],"sessionId":"811f7d7d-b4d3-453c-8338-b14738947912"}
GET /wd/hub/session/811f7d7d-b4d3-453c-8338-b14738947912/window_handles 200 7ms - 98
debug: Appium request initiated at /wd/hub/session/811f7d7d-b4d3-453c-8338-b14738947912/window
info: Remote debugger is already connected to window [3]
debug: Request received with params: {"name":"3"}
info: Responding to client with success: {"status":0,"value":"3","sessionId":"811f7d7d-b4d3-453c-8338-b14738947912"}
POST /wd/hub/session/811f7d7d-b4d3-453c-8338-b14738947912/window 200 1ms - 88
debug: Appium request initiated at /wd/hub/session/811f7d7d-b4d3-453c-8338-b14738947912/element
debug: Request received with params: {"using":"id","value":"userName"}
info: [REMOTE] Executing 'find_element' atom in default context
recv {"result":{"result":{"type":"string","value":"{\"status\":0,\"value\":{\"ELEMENT\":\":wdc:1368002061154\"}}"},"wasThrown":false},"id":1}
info: Responding to client with success: {"status":0,"value":{"ELEMENT":"5000"},"sessionId":"811f7d7d-b4d3-453c-8338-b14738947912"}
POST /wd/hub/session/811f7d7d-b4d3-453c-8338-b14738947912/element 200 13165ms - 112

We are getting close... any help would be really appreciated.

Thanks,

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Sergio Neves Barros]

Fixed the issue (listeners were being added in the wrong place).

We were now able to run our tests without sleeps (e.g. find element, setvalue etc...).

We have only tested the basic interactions, but we'll continue to test the rest.

Any feedback is appreciated.

Sergio

On Wednesday, 10 April 2013 17:41:31 UTC+1, Sergio Neves Barros wrote:

[Jonathan Lipps]

Sergio,

This is wonderful progress! When you feel you've had a chance to go over the code, please submit it as a pull request and I'll be happy to review it and go through suggestions on github. Cheers!

Jonathan

[Sergio Neves Barros]

Jonathan,

Just sent the pull request for the webview testing on a real ios device.

I have been able to confirm the following works:

1. Find, Click and SendKeys on a web element
2. Take a screenshot works (even on retina)
3. Page refresh, get title, get source
4. Execute JS on the page

Please make sure you build the latest version of the ios-webkit-debug-proxy manually (and not with brew).

I have asked Google to tag the proxy with the fix, so that it can be installed using brew.

Let me know what you think and if you need me to do any changes.