238516 - Editor: Midas - cannot underline <a> tags

Status: UNCONFIRMED

(Core :: DOM: Editor, defect, P5)

Description

[osavill]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040301
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040301

Take the following HTML:

See the <a href="http://foobar.com">foobar</a> web site

With designMode="on" this is displayed as "See the foobar web site", where
foobar is underlined. However, this HTML may be used in a page where CSS has
defined <a>'s as having no underline, but in this particular case you want to
override this. 

Double click the word foobar and do an execCommand("underline",...)
  foobar remains underlined but the style is not applied to the underlying HTML

Select the space before as well as foobar and do an execCommand("underline",...)
  The underlying HTML now looks like:
see the<span style="text-decoration: underline;"> </span><a
style="text-decoration: underline;" href="http://foobar.com">foobar</a> web site

which, of course, now gives the desired underline but also an undesired one.

bold and italic both work as expected.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[José Jeria]

Can you add a testcase that shows this?

Comment 2

[osavill]

Yes, you can see this on your own Midas demo page as follows: 
 
Goto http://www.mozilla.org/editor/midasdemo/ 
Paste the HTML: 
  See the <a href="http://foobar.com">foobar</a> web site 
into the entry zone (or add it long hand) 
 
Now imagine that the HTML is going into page has CSS with a style : 
   a { color: #19519d; text-decoration: none; } 
so that "foobar" is not underlined, but on this occasion we want it 
underlined... 
 
Double click on the text "foobar" 
Press the "Underline" toolbar button. 
Click in the "Examine HTML Source" checkbox 
   <b><u> No change has been made to the HTML </u></b> 
 
Select the spaces either side of "foobar" as well. 
Press the "Underline" toolbar button. 
   The underline now extends to the surrounding spaces as well. 
Click in the "Examine HTML Source" checkbox 
   The HTML has now been changed to : 
See the<span style="text-decoration: underline;"> </span><a 
style="text-decoration: underline;" href="http://foobar.com">foobar</a><span 
style="text-decoration: underline;"> </span>web site  
 
This delivers the effects described in the original posting. 
 
Expected results: 
   When double clicking "foobar" and pressing the "Underline" toolbar button 
the style="text-decoration: underline;" should have been applied to the <a> 
tag without requiring other text to be selected as well. 

Comment 3

[Bernd]

move unconfirmed midas bugs

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[osavill]

This still happens. 

Comment 6

[Alfonso Martinez]

The summary of the bug isn't clear, it's just the opposite: you can't remove underlining, and as there's already another bug (although it's newer), I'm dupping this one.

*** This bug has been marked as a duplicate of 300358 ***

Comment 7

[osavill]

OK. This bug is different.

Bug 300358 refers to the fact that CSS elements defined in an external CSS file for the page containing the <iframe> element which has designMode applied are not carried into the <iframe> itself. This may or may not be an issue. By using some JavaScript along the lines of       document.getElementById('edit').contentWindow.document.write("<link href='../css/editor.css' type='text/css' rel='stylesheet'>" + strippedHtml);
the IFRAME adopts the styles contained in editor.css.

This issue describes the fact that the text-decoration style is not applied to <a> elements. I've just tried it again to make sure. I.e. if you highlight some already underlined text and press the Underline button a <span> element with a style="text-decoration: none;" is created. If you highlight an <a> element no such style attribute is applied. Even adding your own style="text-decoration: underline;" to the <a> just results in the style being removed from the <a> !!!

Comment 8

[Alfonso Martinez]

err, no, it's the same bug.
Bug 300358 makes no references to frames, it's just a simplified testcase showing that if a frame has designMode on then the style-decoration of <a> aren't applied, just the same that this bug.

Comment 9

[osavill]

I have to disagree. To me it seems that Bug 300358 relates to external styles not being employed inside elements with designMode set "on"; whereas this one is about style attributes not being applied locally for <a> elements when designMode is "on". I.e. it relates to what happens when you do an execCommand("underline", false, null) for an <a> element. Both are genuine issues in their own right since both happen. If you are saying that Bug 300358 covers both these issues then ok, but surely it is better to have an issue report for both issues so one doesn't get forgotten ?

Comment 10

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.