Re: [dev] [surf] [PATCHES] (1) GConf URL schema handlers (2) delete _SURF_GO xprop (3) close stdout sending XID

On 4/7/11, Adam Strzelecki <ono_AT_java.pl> wrote:
> Below you will find patches for latest HG head of *surf* which I am using in
> my project using integrated Linux station.
>
> (1) surf-1-respect-GNOME-URL-handlers.patch
>
> This patch makes *surf* respect URL schema handlers registered in
> GNOME/Gtk/GConf, when requested url is using other schemas than http: or
> https:.
> Since anyway *surf* is Gtk program it was easy to add GConf handling inside
> to open other program registered on
> /desktop/gnome/url-handlers/<schema>/command, such as IRC, IMs.
>
Upstream should avoid depending on GConf. I wouldn't be surprised if
some here would prefer P9 plumbing.

> (2) surf-2-delete-_SURF_GO-once-received.patch
>
> This xprop (atom) may be used to tell *surf* to go to specific URL. It is
> safer to remove this atom just after it is set in case we send some URL
> containing passwords or auth tokens such as
> http://login:mypassword@myserver.com/
> Anyway _SURF_URI will represents current page URL, so keeping _SURF_GO makes
> no sense. In our case it is matter of safety to not expose this one.
>
Is there no race condition inherent? What happens if you try to read
_SURF_GO just after it's set?

> (3) surf-3-close-and-reopen-stdout-when-sending-XID.patch
>
> When using -x option making *surf* emit its window XID currently it does not
> close stdout so:
>
> SURFXID=`surf -x 2>/dev/null &`
>
> will hand forever because no EOF is encountered.
>
> So this patch reopens stdout to /dev/null just after sending XID using -x
> option, so caller process (shell) will receive EOF for stdout and return the
> control.
>
Quite useful indeed.

> I hope these small patches gets accepted into HG repo so, we will be able to
> use *surf* out of the box in our project without need for custom patching.
>
Thanks for submitting, I'll patch locally, in the least.
Received on Thu Apr 07 2011 - 18:36:20 CEST