GNOME Bugzilla – Bug 650219
Don't update chat notifications with outgoing messages
Last modified: 2011-05-24 22:08:03 UTC
Created attachment 187840 [details] [review] telepathyClient: don't update notifications for outgoing messages If you receive a message, a notification will appear. If you reply in Empathy's chat window before the notification disappears, the notification is updated with the contents of the message you *just* sent! We should only update notifications if they're incoming. Check out my patch.
(In reply to comment #0) > Created an attachment (id=187840) [details] [review] > telepathyClient: don't update notifications for outgoing messages > > If you receive a message, a notification will appear. If you reply in > Empathy's chat window before the notification disappears, the > notification is updated with the contents of the message you *just* > sent! Is this a bad thing? > We should only update notifications if they're incoming. > > Check out my patch.
(In reply to comment #1) > (In reply to comment #0) > > If you receive a message, a notification will appear. If you reply in > > Empathy's chat window before the notification disappears, the > > notification is updated with the contents of the message you *just* > > sent! > > Is this a bad thing? Sure. I don't need the shell to notify me about the message I literally just typed. It makes it look as if the remote contact just said the same thing.
Review of attachment 187840 [details] [review]: Ah, I confused with this with another bug. Good catch :) ::: js/ui/telepathyClient.js @@ +416,3 @@ + if (message.direction == NotificationDirection.RECEIVED) + this.update(this.source.title, messageBody, { customContent: true, bannerMarkup: true }); Style nit, but it would be nice if you could break this line into two so it's less than 80 characters.
(In reply to comment #3) > Style nit, but it would be nice if you could break this line into two so it's > less than 80 characters. Cool, thanks. I did that and merged the patch.
This patch points out a bit of a ugliness in the existing code - that when filling a message with history, we're constantly calling update() and changing the banner label, and the last message happens to win and leave the banner label we want. Don't know if that's worth fixing - it probably isn't measurable performance-wise.