Bug 275332 - Approver doesn't start chat windows correctly
Summary: Approver doesn't start chat windows correctly
Status: RESOLVED UPSTREAM
Alias: None
Product: telepathy
Classification: Unmaintained
Component: approver (show other bugs)
Version: git-latest
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: 0.4.0
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-10 12:29 UTC by Francesco Nwokeka
Modified: 2012-07-06 12:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco Nwokeka 2011-06-10 12:29:55 UTC
Version:           git-latest
OS:                Linux

The approver doesn't handle more than one chat. Let me explain.
This bug came out whilst testing different protocols. I was talking to a friend and another one wrote to me whilst i had the chat open. I pressed the "respond" button but no new chat window was created.



Reproducible: Always

Steps to Reproduce:
1 - open a chat
2 - make someone else write to you
3 - click the "respond" button shown by the approver


Actual Results:  
no new chat window is spawned

Expected Results:  
another chat window in the chat tab to be shown with the new user
Comment 1 Martin Klapetek 2011-07-18 18:04:43 UTC
What's the state of this bug? Nwoki can you confirm this is still present?
Comment 2 Martin Klapetek 2011-12-06 14:21:32 UTC
Here are my observations on this bug.

It looks like it's Plasma/StatusNotifierItem fault. If I receive new message and I click the 'Respond' button *before* the notification timeout limit, it works. However clicking it after does nothing. 

In other words - if you have visible the notification plasmoid, it shows little "1" when you receive new message. While that "1" is displayed, the notification is working. Once the "1" is gone and the plasmoid fades to its normal state (after the timeout), the notification stays visible but does not work anymore.

I don't think we can do anything in our code to fix this (except hiding the notification after timeout). I'll try investigate it upstream.