DESCRIPTION: If a :first-letter pseudo-element contains a letter that is part of a link, hovering over that link destroys all of the styles that are associated with the pseudo-element. STEPS TO REPRODUCE: 1) load attached test case 2) hover mouse pointer over link ACTUAL RESULTS: * after (1) above, the first letter of the link is red and double the font size of the rest of the text * after (2) above, the first letter is no longer red and large EXPECTED RESULTS: * the first letter should stay red and double the font size no matter what. DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-01-10-08-M13 ADDITIONAL INFORMATION: Alan Flavell pointed this bug out to me. It also occurs on his page http://ppewww.ph.gla.ac.uk/~flavell/www/

Block/inline issue so re-assigning to Kipp's bug list

mass-moving bugs to M15

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

mine! mine mine mine! all mine! whoo-hoo!

moving all buster m15 bugs to m16.

won't make beta1

Marc: is this a bug you could look at? It seems that the mouseover event is causing style to get re-resolved incorrectly for the first letter frame. I'll attached a frame & style context dump for before and after the mouseover event.

Unless this is easy, it's a good candidate for FUTURE. Setting first letter properties on a link should be relatively uncommon. We could release note it and then fix it for a future version without preventing adoption of the feature by content developers (it would just look ugly in FCS). buster's call.

This is a nasty problem - the :first-letter is applied to the P, however the first letter on the line is in an A, so when we re-resolve the pseudo style for the :first-letter rule we don't find any matches. The key is to find out how it works initially, since the problem is in dealing with re-resolving the style after the content states have changed. Still looking... Putting a character in front of the <A ...> make it work fine, of course.

At Frame Construction time, the block recognizes that there is a first letter rule on the P and calls WrapFramesInFirstLetterFrame, which in turn calls GetFirstLetterStyle which resolves the pseudo style and of course matches the rule P:first-letter. When the hover happens, however, the ContentChanged method only gets called with the A content, not the P, so the rule does not match and the first-letter frame gets removed. Fixing this probably means somehow getting the ContentChanged call for the A to check and see if it is providing the first-letter for its parent... ugh. Any other ideas? As a note: IE does not support this at all.

In IE, it doesn't work if the <A> is a <FONT> or a <SPAN>...the type of inline frame is irrelevant: first-letter is ignored. So changing summary. I think we have to either fix this (making us more functional than IE), or disable first-letter in an inline. Could just future it.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

I'm changing the title again because the new one is wrong. :first-letter *does* work with inline frames, but it gets messed up on *restyle* (which happens when moving over the link). I think the new one is accurate...

*** Bug 49147 has been marked as a duplicate of this bug. ***

changing qa contact to chrisd.

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that do not have the "testcase" keyword and yet have an attachement with the word "test" in the description field. Apologies for any mistakes.

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

*** Bug 96043 has been marked as a duplicate of this bug. ***

*** Bug 103248 has been marked as a duplicate of this bug. ***

Bug 103248 made the interesting observation that the cause of this bug is applying the :first-letter style of the inline rather than the :first-letter style of the block -- perhaps we're just doing style resolution for the pseudo-element against the wrong element?

*** Bug 111794 has been marked as a duplicate of this bug. ***

*** Bug 119713 has been marked as a duplicate of this bug. ***

Related, perhaps, to this bug is the fact that if you define both :first-letter and :first-line psuedo elements for a paragraph element with a link as the only content, the :first-letter style goes away upon hover, but not the :first-line style... I'll attach a test case as well. FYI: IE 6.0 on Windows XP Pro does not have this bug... at least not with this userAgent string: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)

Hope this helps in some way...

*** Bug 130179 has been marked as a duplicate of this bug. ***

*** Bug 131076 has been marked as a duplicate of this bug. ***

*** Bug 133079 has been marked as a duplicate of this bug. ***

*** Bug 138122 has been marked as a duplicate of this bug. ***

*** Bug 144806 has been marked as a duplicate of this bug. ***

*** Bug 153286 has been marked as a duplicate of this bug. ***

I discovered this same problem with Mozilla 1.0 on Windows 2000 yesterday. After hovering over an anchor that begins a paragraph with the first-letter pseudo-element defined, the first-letter setting is forgotten.

*** Bug 162625 has been marked as a duplicate of this bug. ***

*** Bug 163167 has been marked as a duplicate of this bug. ***

*** Bug 166488 has been marked as a duplicate of this bug. ***

Hmm. I just checked the testcase, and the bug as described is indeed fixed. But now, I noticed a similar problem: the :first-letter style is still forgotten if I *click* the link! Shall I file another bug?

The testcase in attachment 4118 [details] still shows the bug for me (in a Linux build from a few days ago).

Oh, I probably see it because I have a :hover rule in my userContent.css. Yes, without a :hover rule you wouldn't see the bug anymore thanks to the optimizations made for bug 5693. This bug is still valid, it just needs a new testcase.

This is modified so that it still shows the bug after the changes for bug 5693.

*** Bug 186481 has been marked as a duplicate of this bug. ***

What's up with this bug? Anyone working on this?

*** Bug 212647 has been marked as a duplicate of this bug. ***

This bug still exists as of Mozilla 1.6a.

*** Bug 230132 has been marked as a duplicate of this bug. ***

*** Bug 240467 has been marked as a duplicate of this bug. ***

*** Bug 245211 has been marked as a duplicate of this bug. ***

*** Bug 260944 has been marked as a duplicate of this bug. ***

*** Bug 300634 has been marked as a duplicate of this bug. ***

This bug still exists as of Firefox 1.5b1

Bug still present on the trunk (gecko 1.9a1). I was about to open a new bug and therefor created some testcases. I'll attach these because I think they show a little more of the odd behaviour.

*** Bug 353326 has been marked as a duplicate of this bug. ***

This bug still exists as of Firefox 2.0.0.3.

(Marking this bug as the dupe rather than the other one 'cause bug 399384 has more (and more current) debugging info posted.)

(Fixed by checkin for bug 399384.)