style change in mouseover badly influence how altenate stylesheet are applied

RESOLVED WORKSFORME

Status

()

Core
CSS Parsing and Computation
P3
normal
RESOLVED WORKSFORME
16 years ago
7 years ago

People

(Reporter: Benoit Maisonny, Unassigned)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826

The testcase shows 2 sets of 2 <li>, each li triggers a change of stylesheet
declared in <link> tags (one initial, one alternate stylesheet).

The first set of li has mouseover and mouseout handlers to change the background
color. The second set doesn't.

Reproducible: Always

Steps to Reproduce:
1. Open the URL given
2. click on the 2nd line of text ("set to Red with mouseover")
3. click on the 1st line to get back to Blue
4. repeat 2. and 3. a couple of times, because the 1st time is different

5. click on the 4th line of text ("set to Red without mouseover")
6. click on the 3rd line to get back to Blue
7. repeat 5. and 6. a couple of times, because the 1st few times are different
8. Notice the difference of behaviour between the 2 sets

Actual Results:  
When the 1st set is used to change stylesheets, the CSS is not completely
applied: the text color changes, but not the list-style-type.


Expected Results:  
The second set has the correct behaviour. Both sets should behave the same.

You should experience this with the menu View, Use style as well. Try using the
mouse, after having played with the first set and also with just the keyboard
(in order not to trigger any mouse events). Try also different things after
having reloaded the page, as it seems it has influence in som cases.


Also tested with Mozilla 1.2b on win98 (20021016), same wrong result.
Works with IE5.5 (except the first time, but this is another story...)

Not sure if it is about Event handling or style system, or anything else, in fact.
(Reporter)

Updated

16 years ago
Keywords: testcase

Comment 1

16 years ago
the URL/testcase timeed out, but it sounds like you might be seeing bug 130620
(Moz 0.9.9 misses mouseout events if the background color is changed).  If
that's what you're seeing, please mark this as a dupe.
(Reporter)

Comment 2

16 years ago
Sorry, my ADSL was down all day: that's why the testcase timed out. It's up
again now.

I don't think it is a dup of bug 130620. They might be related, and I actually
encountered that bug too when developing my application, but I worked hard
enough on my testcase to separate both issues.

Bug 130620 is about missing mouseout events. My testcase does not miss any
event. Instead, it misses complete application of an alternate stylesheet. The
stylesheet should be applied before the mouseout anyway.

I have done further tests (see changed URL), and I now think that it is not
related to the events (or at least not directly), but rather to the style change
in event handlers. I added 2 more tests to show this:

- The 3rd set of li's is similar to the 1st set, only the style property changed
is textDecoration instead of backgroundColor. This set has the same problem as
the 1st one.

- The 4th test changes the innerHTML of its 3rd li to show mouse over/out
events. This shows that not only we don't miss any event, but the events don't
influence the change of style sheets (i.e. the stylesheet is applied even on
this 4th set).

I am changing the title according to this (maybe a better english speaker can
find a more explicit title). I am also changing the component affected.
Component: Event Handling → Style System
Summary: mouseover and mouseout badly influence how stylesheet are applied → style change in mouseover badly influence how altenate stylesheet are applied
(Reporter)

Comment 3

16 years ago
Interestingly, the bug does not appear when using :hover pseudo class on the
element. One could think that having a property set for a selector with :hover
would be the same as setting the same property in a onmouseover/out handler.
Well, it is not the case.

So this is a workaround for this bug: use :hover instead of onmouseover/out
handlers. Unfortunately, IE5.5 only accepts :hover on <a href="...">. So it is
not an easy, multi-platform workaround.
(Reporter)

Comment 4

16 years ago
Tested with Moz 1.2b on Linux: same problem. Setting platform to All.
OS: Windows NT → All

Comment 5

16 years ago
reassign

so (just to make sure I know what's going on) the problem is that the bullets
disappear? (with 1st and 3rd set, the 4th seems to work ok)
Assignee: joki → dbaron
QA Contact: rakeshmishra → ian
(Reporter)

Comment 6

16 years ago
The list-style-type (yeah, bullet) is not applied to the set that is used to
switch stylesheets, IF another style is changed in that set's mouse event handler.

In each set one bullet is switched on and the other off, alternatively: that's
normal.

Use sets 2 and 4: they work well.
Use sets 1 and 3: they show the bug.

Comment 7

16 years ago
what i see ....

1st set : (shift+reload page)
=========
1) click on "Click here to set to Red (with mouseover/out)" :-
   - color changes to red
   - no bullets in any of the list items
2) click on "Click here to set to Blue (with mouseover/out)" :-
   - color changes to blue
   - DISC  bullets in the list items with class "Blue" in sets 2, 3, and 4
3) now click on "Click here to set to Red (with mouseover/out) :-
   - color changes to blue
   - DISC  bullets in the list items with class "Blue" in sets 2, 3, and 4
4) now click on "Click here to set to Blue (with mouseover/out)" :-
   - color changes to blue
   - DISC  bullets in the list items with class "Blue" in sets 2, 3, and 4

2nd set : (shift+reload page)
=========
1) click on "Click here to set to Red (with mouseover/out)" :-
   - color changes to red
   - no bullets in any of the list items
2) click on "Click here to set to Blue (with mouseover/out)" :-
   - correct behaviour
3) now click on "Click here to set to Red (with mouseover/out) :-
   - correct behaviour
4) now click on "Click here to set to Blue (with mouseover/out)" :-
   - correct behaviour

3rd set : (shift+reload page)
=========
1) click on "Click here to set to Red (with mouseover/out)" :-
   - color changes to red
   - no bullets in any of the list items
2) click on "Click here to set to Blue (with mouseover/out)" :-
   - color changes to blue
   - DISC  bullets in the list items with class "Blue"  in sets 1, 2 and 4
3) now click on "Click here to set to Red (with mouseover/out) :-
   - color changes to rede
   - DISC  bullets in the list items with class "Red"  in sets 1, 2 and 4
4) now click on "Click here to set to Blue (with mouseover/out)" :-
   - color changes to blue
   - DISC  bullets in the list items with class "Blue"  in sets 1, 2 and 4

4th set : (shift+reload page)
========= 
1) click on "Click here to set to Red (with mouseover/out)" :-
   - color changes to red
   - no bullets in any of the list items
2) click on "Click here to set to Blue (with mouseover/out)" :-
   - correct behaviour
3) now click on "Click here to set to Red (with mouseover/out) :-
   - correct behaviour
4) now click on "Click here to set to Blue (with mouseover/out)" :-
   - correct behaviour

another note:-
the behaviour of each set differs on each simple 'reload'

confirming the bug 

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
(Reporter)

Comment 8

16 years ago
I guess that on 1st set, 3rd action, you meant that color changes to red.

Now, if you compare those results with using the menu View/Use style (using the
keyboard only, preferably), you will see that the bug never appear in the latter
case, not even at the first stylesheet switch.

Comment 9

16 years ago
Created attachment 105897 [details]
blue.css

style sheet 'blue'

Comment 10

16 years ago
Created attachment 105898 [details]
red.css

style sheet 'red'

Comment 11

16 years ago
Created attachment 105899 [details]
testcase 

copied testcase provided in the url as an attachment
(Reporter)

Comment 12

13 years ago
Fixed in FF1.5:
Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8) Gecko/20051111 Firefox/1.5
Assignee: dbaron → nobody
QA Contact: ian → style-system
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.