Evolution Freezes when you Insert an Emoticon (Smiley Face)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gtkhtml4.0 (Ubuntu) |
Fix Released
|
Medium
|
Mathieu Trudel-Lapierre | ||
Precise |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
Evolution becomes unresponsive due to GtkHtml not ungrabbing input; this may also affect other applications. When using HTML editing, changing font color or adding emoticons causes the input to be grabbed and never released.
[Test Case]
1) Open Evolution
2) Compose a new message (Click the "New" button at the left of the toolbar)
3) Switch to HTML mode if necessary using the combo box at the bottom left of the message header.
4) Change font color.
[Regression Potential]
Potential regression scenarios include issues with editing messages as HTML; including how the message will be formatted when received or whether other parts of the message composer UI become unresponsive or don't appear to produce results.
---
I was writing an Email and I decided to insert an emoticon (smiley face) and instead of inserting the emoticon to where the pointer was, it inserted the emoticon in the beginning of the email and then Evolution COMPLETELY froze. My system was working fine, but Evolution froze and I had to use Terminal to "xkill" the Program, then I restarted the program and it "autosaved" my email with the emoticon.. Some other users may not be as lucky, however..
Please fix this bug...
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: evolution 3.2.3-0ubuntu6
ProcVersionSign
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Fri Jun 8 16:49:17 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: evolution
UpgradeStatus: No upgrade log present (probably fresh install)
Changed in evolution (Ubuntu Precise): | |
status: | New → Triaged |
importance: | Undecided → Medium |
assignee: | nobody → Mathieu Trudel-Lapierre (mathieu-tl) |
Changed in evolution (Ubuntu): | |
status: | Confirmed → In Progress |
description: | updated |
Changed in gtkhtml4.0 (Ubuntu Precise): | |
status: | Triaged → In Progress |
Changed in gtkhtml4.0 (Ubuntu Precise): | |
assignee: | Mathieu Trudel-Lapierre (mathieu-tl) → nobody |
tags: | added: verification-needed |
Confirmed.
It seems it's not actually frozen, because windows respond properly to the signals sent from hitting the [X] window close button at the top; but it's indeed completely impossible to interact with the window until it's killed and started again.
gdb reports nothing unusual, strace just that it's still polling for some GDK events that never come, if my assessment is correct.
I'm assigning this to myself as a reminder to check back on it in a few hours (tomorrow work hours), and because this will need to be brought up with upstream.
Patrick; please don't assign yourself to bugs unless you're planning on working on a fix, which is what this would mean ;) The bug is otherwise already correct, and you're subscribed to it since you're the one who reported it; so you'll get messages for all updates.