[Bug 63326] haze should support purple_account_request_password()

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63326

--- Comment #2 from Will Thompson <will.thompson at collabora.co.uk> ---
Comment on attachment 77742
  --> https://bugs.freedesktop.org/attachment.cgi?id=77742
Version 2 of the proposed change

Review of attachment 77742:
 --> (https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=63326&attachment=77742)
-----------------------------------------------------------------

I think this will still leak, actually. Take a look at pidgin/request.c's
implementation of request_fields: if the user closes the window without picking
a response, it makes sure to call the cancel_cb before purple_request_close().
This allows whatever bit of libpurple made the request to clean up.

But if that's fixed, I think it looks good.

::: src/request.c
@@ +27,3 @@
>  
>  #include "debug.h"
>  #include "request.h"

What happens if libpurple gives us a password request, and before the user
answers the challenge, libpurple cancels it?

I think what will happen is: haze_close_request() is called by libpurple,
freeing this stuff up.

Then later, haze_request_password_cb() will be called, which will call back
into libpurple with a freed request and crash.

@@ +33,2 @@
>  static gpointer
>  haze_request_input (const char *title,

Use g_slice_free (fields_data, fd);

@@ +104,5 @@
> +struct password_data {
> +    PurpleRequestFields *fields;
> +    PurpleRequestField *password;
> +    GCallback ok_cb;
> +    GCallback cancel_cb;

I think it would be better to cast these to PurpleRequestFieldsCb in
haze_request_fields, not at the point you call them. I think that would be
clearer.

@@ +138,4 @@
>                       PurpleConversation *conv,
>                       void *user_data)
>  {
> +    /*

Use g_slice_new0.

@@ +166,2 @@
>  
>      return NULL;

I think the idle callback should call the cancel_cb, so that whatever made the
request doesn't leak.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.