If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Styles trying to set text-decoration don't work on anchors inside <body contenteditable="true">

UNCONFIRMED
Unassigned

Status

()

Core
Editor
UNCONFIRMED
7 years ago
7 years ago

People

(Reporter: Aaron Maenpaa, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7 KilnClientv0.1 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7 KilnClientv0.1 ( .NET CLR 3.5.30729)

Rules such as "a{ text-decoration: none; }" fail to remove the underline on <a>s inside of <body contenteditable="true">.

This is reproducible in Minefield (August 25) for all links and for unvisited links in FireFox 3.6

(I'll attach the webpage I'm using to repro.)

Reproducible: Always

Steps to Reproduce:
1. Open the attached html page.
2. See that the links are underlined even though their text-decoration should be none.
(Reporter)

Comment 1

7 years ago
Created attachment 469196 [details]
HTML page that can be used to reproduce the problem.

Comment 2

7 years ago
I see this in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100904 Firefox/4.0b6pre
Component: General → General
Keywords: testcase
OS: Windows Server 2003 → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Version: unspecified → Trunk
contenteditable.css is an override sheet that gets loaded and applies to editable content and styles anchors.  

The relevant part of that file:

82 /* We suppress user/author's prefs for link underline, 
83    so we must set explicitly. This isn't good!
84 */
85 a:link:-moz-read-write {
86   text-decoration: underline -moz-anchor-decoration;
87   color: -moz-hyperlinktext;
88 }

Peter, do you recall why that's needed?

Aaron, you should be able to use !important declarations to get around this, I think....
Component: General → Editor
QA Contact: general → editor
Hmm, that CSS rule seems silly to me...  I can't think of any reason why that's needed.
Duplicate of this bug: 300358

Updated

7 years ago
Blocks: 424615
You need to log in before you can comment on or make changes to this bug.