Style is not reverted when removing a class through script

RESOLVED WORKSFORME

Status

()

Core
DOM: CSS Object Model
RESOLVED WORKSFORME
14 years ago
12 years ago

People

(Reporter: Erik Funkenbusch, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031116 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031116 Firebird/0.7+

When a class is added to an element programmatically (though it may not depend
on the style being added) the new style is correctly applied.  However, when the
class is removed from the element, the style does not revert back to it's
original (either default or style sheet defined) setting.

Reproducible: Always

Steps to Reproduce:
1. Load a page with the attached HTML/JavaScript

2. Move the mouse pointer over the "Test" element, which will cause another UL
block to be unhidden like a drop-down menu.  

3. Move the mouse out of the element, notice that the element does not revert
back to display:none which is defined by the style #nav ul

Actual Results:  
The display:none style is not applied to the element as it should be.

Expected Results:  
The #nav ul style should be applied to the class, in particular the
display:block style should revert back to display:none
(Reporter)

Comment 1

14 years ago
Created attachment 136393 [details]
A suitable testcase for verifying the bug
(Reporter)

Comment 2

14 years ago
The correct overriding style should be #nav li ul, not #nav ul. 

Updated

14 years ago
Keywords: testcase

Comment 3

14 years ago
Created attachment 136416 [details]
Better testcase showing classNames

This modification shows in the title of the window the className after each
change, and it shows that what happens it's that the className becomes " over
over". Then when the onmouseout event is executed the class becomes only "
over".

I don't know what it's really happening, if it's a bug (the double "over" and
the left one after replacing them in mouse out) of Mozilla or not (maybe that's
really what it should do according to the script), but a way to work around it
is by changing the first function to do a replace first:

node.onmouseover=function() {
	this.className=this.className.replace(" over", "");
	this.className+=" over";
}
(Reporter)

Comment 4

14 years ago
Interesting.  If you are extermely careful, you can see how this case plays 
out.  if you move your mouse along the top margin above the element, then move 
the mouse down so it just barely touches it.  You will notice that moving it 
off the element functions correctly.  

It's only when you move the mouse over the newly unhidden list that the 
problems begin.  Moving it down so that it moves over the first LI then the 
titlebar still says *over*, but if you either move it back over the parent 
element or move it to the second LI then it changes to * over over*.

This may be a different scenario of another bug I filed relating to the 
onmouseout not firing in weird circumstances relating to the first element.  
See bug http://bugzilla.mozilla.org/show_bug.cgi?id=226894 .  In fact, I think 
it's quite likely it's a different expression of it.

Comment 5

12 years ago
Created attachment 224045 [details]
testcase

This testcase has an additional 
this.className=this.className.replace("over", "");

Comment 6

12 years ago
The this.className=this.className.replace(" over", ""); doesn't work, because the className is trim-ed (IMO) in the newer versions.

I don't see why this bug is still here with UNCONFIRMED anyway, because the testcase works for me. Did I miss something?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060531 Minefield/3.0a1
This is certainly a WFM as demonstrated by the last testcase and lots of sites on the net, the original testcase appears faulty.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

12 years ago
(In reply to comment #7)
> This is certainly a WFM as demonstrated by the last testcase and lots of sites
> on the net, the original testcase appears faulty.
> 

Actually, what this turns out to be is a difference in implementation between IE and Gacko.  I'm not sure which implementation is correct, or if it's just one of those "unspecified" things.

Gecko (at least in FF) will strip the leading space off the first class, while IE will not.  Check the second test case in both FF and IE, notice how the classname in IE stays " over" while the classname in FF is simply "over".  

I'm not sure if Gecko should be stripping anything out of data that's applied to  any field.  

I've re-opened this to discuss this side-effect.  Maybe we'll just close it again if this is the correct implementation, but I don't want it ignored because it's resolved.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Closing again. That is a separate issue and if you wish to discuss it then feel free to open a dedicated bug on it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.