Bug 626690 - [mail] HTML format - header 1 size Text becomes Normal after selecting strike, italic, underline format
Summary: [mail] HTML format - header 1 size Text becomes Normal after selecting strike...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gtkhtml3 (Show other bugs)
(Show other bugs)
Version: 6.1
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Matthew Barnes
QA Contact: Desktop QE
Keywords: Desktop, Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-24 06:13 UTC by A S Alam
Modified: 2014-01-02 10:25 UTC (History)
4 users (show)

Fixed In Version: gtkhtml3-3.32.2-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-21 04:58:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1540 normal SHIPPED_LIVE Low: evolution security, bug fix, and enhancement update 2013-11-21 00:40:51 UTC

Description A S Alam 2010-08-24 06:13:02 UTC
Description of problem:
While writing text in HTML format (in mail), select text - Header 1, then use 'underline' for selected text, then Text becomes Normal and 'Header 1' setting lost.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run evolution
2. write a new mail, select format HTML
3. type some text, Select it, Select Header 1
4. Now select Underline
Actual results:
text becomes normal

Expected results:
it should be same size

Additional info:
If try reverse, Select Text->Underline->Header 1, it is Working.

Comment 2 A S Alam 2010-08-24 06:14:18 UTC
Bug #586869 may be related to this issue

Comment 3 Milan Crha 2010-08-24 13:05:44 UTC
Thanks for a bug report. I see this on actual master too. I also see that the paragraph style combo box has still chosen "Header 1" and saving this as a draft and reopening makes it show the text as expected. It might be something with internal structures going wrong.

Comment 4 Matthew Barnes 2010-11-30 03:24:18 UTC
This is a GtkHtml issue and the problem is still unsolved upstream, so NAK for 6.1.

Comment 5 RHEL Product and Program Management 2010-11-30 03:24:56 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 6 Matthew Barnes 2010-12-01 00:58:12 UTC
Proposing for 6.2.

Comment 7 RHEL Product and Program Management 2011-07-05 23:44:38 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support

Comment 8 Milan Crha 2013-06-27 12:52:19 UTC
Hmm, still reproducible on git master (4.6.5), though the upstream focuses on a replacement of GtkHTML editor with a Webkit based editor.

Comment 9 Milan Crha 2013-07-02 15:09:16 UTC
Acking, an upstream patch available:

Comment 11 Vladimir Benes 2013-07-03 14:32:38 UTC
reproducer in comment#0
-> qa_Ack+

Comment 16 errata-xmlrpc 2013-11-21 04:58:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.