Bug 626690 - [mail] HTML format - header 1 size Text becomes Normal after selecting strike, italic, underline format
[mail] HTML format - header 1 size Text becomes Normal after selecting strike...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gtkhtml3 (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Matthew Barnes
Desktop QE
: Desktop, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-24 02:13 EDT by A S Alam
Modified: 2014-01-02 05:25 EST (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description A S Alam 2010-08-24 02:13:02 EDT
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):
evolution-2.28.3-10.el6.x86_64
gtkhtml3-3.28.3-3.el6.x86_64
evolution-mapi-0.28.3-6.el6.x86_64
evolution-help-2.28.3-10.el6.noarch
evolution-data-server-2.28.3-10.el6.x86_64

How reproducible:
every-time


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 02:14:18 EDT
Bug #586869 may be related to this issue
Comment 3 Milan Crha 2010-08-24 09:05:44 EDT
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-29 22:24:18 EST
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-29 22:24:56 EST
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 6 Matthew Barnes 2010-11-30 19:58:12 EST
Proposing for 6.2.
Comment 7 RHEL Product and Program Management 2011-07-05 19:44:38 EDT
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
representative.
Comment 8 Milan Crha 2013-06-27 08:52:19 EDT
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 11:09:16 EDT
Acking, an upstream patch available:
https://git.gnome.org/browse/gtkhtml/commit/?h=gnome-3-6&id=b2ee0cbb5f46d2e8d3b910ceb5a59429cbbae955
Comment 11 Vladimir Benes 2013-07-03 10:32:38 EDT
reproducer in comment#0
-> qa_Ack+
Comment 16 errata-xmlrpc 2013-11-20 23:58:18 EST
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.

http://rhn.redhat.com/errata/RHSA-2013-1540.html

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