Opened 12 years ago

Last modified 8 years ago

#1034 new patch

Own User Info background color reverts to white on edit

Reported by: Johnny K Owned by: seanegan
Milestone: Patches Needing Review Component: pidgin (gtk)
Version: 2.0 Keywords: user info
Cc:

Description

Accounts > [account name] > "Set User Info..."

If you set the background to a color (via the "Select Background Color" dialog), that background color will be used in your user info.

However, the next time you edit your User Info via "Set User Info", the background is reverted to the default (#FFFFFF, white). To keep your desired background, you have to choose it again via the "Select Background Color" dialog.

Attachments (1)

consistent_behavior.patch (837 bytes) - added by lukas_p 8 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 12 years ago by lschiere

  • Component changed from winpidgin (gtk) to pidgin (gtk)
  • Milestone set to 2.0.3
  • Owner changed from datallah to seanegan

comment:2 Changed 12 years ago by seanegan

  • Milestone changed from 2.0.3 to 2.1.0

Milestone 2.0.3 deleted

comment:3 Changed 12 years ago by seanegan

  • Resolution set to fixed
  • Status changed from new to closed

Fixed for 2.1.0

comment:4 Changed 12 years ago by seanegan@…

(In 6778b9e770331dedbf2e31f4edbbca4b854d939d) Removes the 'remove all buffer tags' function from gtkimhtml's close_tags() function. The problem was that the BACKGROUND tag is always at the end iter, and we don't want to remove that. The toggle functions called above it should do the trick of properly resetting everything, and it does seem to. Fixes #1034

comment:5 Changed 12 years ago by Johnny K

I don't know if I would consider this fixed.

Now, the "User info..." dialog doesn't let you modify the background color at all.

comment:6 Changed 12 years ago by Johnny K

My apologies. I figured out how to add background color.

However, the same problem still exists. The background color still reverts to white with additional edits.

comment:7 Changed 12 years ago by pomp

Yes, I can confirm too. Using 2.1.0 and it still doesn't save the background color. :\.

comment:8 Changed 12 years ago by seanegan

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:9 Changed 12 years ago by pomp

Alrighty. I am using 2.1.1 .. and it still will not keep the background color after you set it and click "Save" .. :-\

comment:10 Changed 12 years ago by lschiere

  • Milestone changed from 2.1.0 to 2.2.1

comment:11 Changed 11 years ago by bernmeister

Can you please confirm this issue in 2.5.0 and the steps to reproduce?

comment:12 Changed 11 years ago by Johnny K

Confirmed in 2.5.0

Steps to reproduce:

  1. Go to Accounts > [account name] > Set User Info...
  2. Click Font > Background color. Select black, or any color other than white.
  3. Click Save
  4. Again go to Accounts > [account name] > Set User Info...
  5. Background is now default (white)

comment:13 Changed 10 years ago by rekkanoryo

It appears that the problem here is that we're not saving the background color when it applies to the whole profile. If you select a background color specifically for the text, it works.

Changed 8 years ago by lukas_p

comment:14 Changed 8 years ago by lukas_p

Anybody mentioned, that this can be reproduced in most text boxes like normal chats too?

Steps to reproduce: "New instant message..." -> enter a alias (for example your own ICQ-Number) -> enter some text -> do not select it -> change background color -> send it

Result: sent message has previous background color instead of the recently selected background color.

Expected: sent massage has recently chosen background color

For me, this is somehow an inconsistent/strange behavior: For every other formatting that users modify (bold, underline, font-size, ...) the changes are only applied to newly entered or selected text.

If you change the background color (without having anything selected) the background is applied to the whole text an suggests it is actually changed (but it is not). If then, users enter some more text, this new text will have that background.

I solved it by not changing the "body color" but to add "font background color" to newly entered text and thus behave like every other change to the formatting. See patch. Yes, this is a heavy change of the imhtml backend (read: "setting the body color gets nearly impossible"). It will affect all other imhtml-enabled text boxes.

I also thought of making an exception only for the "body background color" or - if there should not be an exception - we could check all formatting options to be set right before saving. The latter would be a "new" consistent behavior.

comment:15 Changed 8 years ago by Robby

  • Milestone set to Patches Needing Review
  • Type changed from defect to patch
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!