44567 - w3.org - Weird effects on w3c's old page (attachment)

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Cesar Eduardo Barros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i586; en-US; m17)
Gecko/20000702
BuildID:    2000070209

The front page in w3.org has changed recently, and somehow it makes mozilla
change color in wierd places to the ugly yellow of the page's right column.

Reproducible:
Always
Steps to Reproduce:
1.Open the page
2.Click in the background of the left column. Try different places
for different effects.
3.Click in the scrollbar "elevator". Try the top, middle and bottom of
it.

Actual Results:  Whatever "box" you clicked in changes its background color to an ugly
yellow

Expected Results:  No color changes

I'll try to save the related files before the webmaster fixes
the ugly page and restore it to its previous state of beauty.

Comment 1

[Cesar Eduardo Barros]

Attachment: The page

Comment 2

[Cesar Eduardo Barros]

Attachment: The stylesheet (StyleSheets/home)

Comment 3

[David Krause]

confirming on linux 2000062808
(yeah i know that's an old build but i'm compiling my cvs build right now) :)

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Temporarily handling joki's bugs.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Doh, forgot to reassign.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I just tested with Linux commercial build 2000072009, and I do not see this
happening. I have also tested with various versions from last week on NT and did
not see this.

Marking WORKSFORME since I cannot reproduce this.

If this still occurs, please reopen the bug and state build number etc. info
where this occurs.

Comment 7

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 8

[Olli Helenius]

Still occurs with Linux Mozilla build ID 2000073120.

Screenshots: http://www.iki.fi/liff/mozbug44567/1.png  (left column)
             http://www.iki.fi/liff/mozbug44567/2.png  (scrollbar)

I also get a pair of these when I click on the left column:
STYLE CHANGE REFLOW. Blowing away all box caches!!

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Tested with normal Mozilla build, and I simply can not reproduce this. I have
RedHat Linux 6.2, uname -a gives:

Linux <HOST ID DELETED> 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686
unknown

I have updated gcc, gdb, ddd & lesstiff from the RH 6.2 dist on my machine if
that amounts to anything.

cesarb, David and Olli, please add comments about your configuration to this bug
so that we could track this down.

I am reassigning this to layout, as I do not think this is an event issue.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Noticed Olli was not on Cc. Olli, can you add comments about your computer's
configuration so we could track this bug down?

Comment 11

[David Krause]

Heikki, I am on redhat 6.2 with all the errata/security updates applied plus a
few packages from the powertools and rawhide collections. 2.2.16 kernel, I also
update gdb, gcc, etc.

Comment 12

[Olli Helenius]

Heikki,

I'm running Debian woody with

Linux puska 2.4.0-test6 #2 Tue Aug 1 13:18:13 EEST 2000 i586 unknown

(the -N in the version numbers below means Debian package version)
gtk+ 1.2.8-1
glibc 2.1.3-10
libstdc++ 2.91.66-4  (the one mozilla-bin is linked to)
gcc 2.95.2-14
gdb 4.18.19990928-1

Verified the bug with Mozilla build 2000080208.

I also noticed that the layout occassionally seems to stretch and shrink
vertically when clicking around.

Hope this helps.

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I have tested both on optimized and debug builds, with classic and modern theme,
but it always works perfectly.

Comment 14

[Nisheeth Ranjan]

Heikki, I'm re-assigning this to you to get this off Clayton's list.  Thanks for
helping out on this one.

Comment 15

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Playing the bug football... Reassigned to style system.

Comment 16

[Marc Attinasi]

I'm seeing this with today's build - taking to investigate.

Comment 17

[Marc Attinasi]

I think that this is correct behavior - somebody please tell me I'm wrong ;}

First, the scrollbar part of the report appears to have been fixed; I cannot get 
the scrollbar to turn yellow, so I'll ignore that part of the bug.

In the stylesheet there is a rule:

td.navbar :active {
   background: #ffc;
   color: #900;
   text-decoration: none;
}

This rule says *any* element in the cell of class navbar that is active should 
get a background color of #ffc. So, we match any element that is active (i.e. 
that the mouse is clicked on) and draw the background color...

There is another similar rule:

:active {
   background: #ffc;
   color: #900;
   text-decoration: none;
}

that says _any_ element that is active should get a background color as well, 
and that causes the background color changes on much of the rest of the page.

I had run across this previously, and decided to put in a QuirkMode hack to not 
match :active to the body, however in Standard mode we match the :active 
selector as dictated by the CSS2 spec, hence the behavior seen.

I do not know why Opera4 and IE5 don't match :active to every element, but it 
appears that they don't.

Considering marking this INVALID, but waiting for some feedback on my 
interpretation of the :active selector and our matching. CC'ing David Baron for 
his input.

Comment 18

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This is a complicated issue.  See bug 5693.

By CSS2, this is acceptable behavior (in fact, we should probably show the
background more).  However, CSS3 is probably going to introduce a property that
defines the behavior much more clearly.  So maybe we should change the way we
handle :active so it's more like a hard-coded version of CSS3?  I dunno.

See CSS2:
http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes
In particular: "The :active pseudo-class applies while an element is being
activated by the user. For example, between the times the user presses the mouse
button and releases it."

One would think that an element with an onclick handler should be able to become
:active according to that paragraph, but CSS doesn't allow any way to do that.  

See CSS3 draft:
http://www.w3.org/TR/css3-userint#pseudo-active
http://www.w3.org/TR/css3-userint#user-input

It probably wouldn't be very hard to just implement a -moz-user-input property
and only let elements that are '-moz-enabled' match :active...

Comment 19

[Hixie (not reading bugmail)]

Of course, if we had the time to do this by beta3, we'd also have the time
to do some of the rather more important CSS1 bugs, so as QA contact, I'm going
to gently move this to Future...

Comment 20

[Marc Attinasi]

Agreed, Ian. 

I'll just add that I already hard-coded the event-sensitive elements in 
nsCSSStyleSheet (used only in QuirksMode) in the static method IsEventSensitive 
(which is really a hack).  It's not as elegant as using the -moz-user-input 
property, but using that property would involve having the EventStateManager 
query the style to determine if the element's state should be updated.

Comment 21

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

A thought -- since our current behavior is perhaps worse than doing nothing
(since we make it :active only if the click is directly on the element rather
than its children), maybe that hack should apply to :active all the time
(changed from quirks only), and :hover in quirks mode (no change)?

Comment 22

[Hixie (not reading bugmail)]

Or we could just fix bug 5693, which is nsbeta3+ and would remove that problem.

Comment 23

[R.K.Aa.]

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

Comment 24

[Hixie (not reading bugmail)]

The weird effects should IMHO be -> evang. The CSS3 draft won't be ready 
for a _long_ time, and I have some serious issues with some of its core 
concepts! ;-)

However, there is another "weird effect" on www.w3.org that needs investigation.
I have filed it as bug 63190.

Comment 25

[Zach Lipton [:zach]]

I think this is a dup. I'll find it when I am done hacking bugzilla into a test-
suite managment system (it might take a while, don't hold your breath)

Comment 26

[Blake Ross]

Reassigning evangelism bugs to [e-mail].

Comment 27

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 28

[R.K.Aa.]

I no longer see this bug on Linux. Fixed, or something changed on page?

Comment 29

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I still see some problems.  But bug 59825 / bug 91794 was fixed recently.  Which
problems went away recently?

Comment 30

[R.K.Aa.]

i was testing the "steps to reproduce" as originally reported. I tested this bug
long ago and used to see weird yellow in unexpected areas, but i no longer see that.

(Clicking AFTER a link IN a yellow area will render the end of that "line" in
the yellow field slightly brigher yellow, but isn't that's the intended effect?)
Earlyer, even areas that initially display on white background used to go yellow
when clicking around. I simply can't trigger this bug anymore.

Comment 31

[Bob Clary [:bc] (inactive)]

-> Eric.

Comment 32

[Andrew Hagen]

This page looks good now, using Build ID: 2002021503 (0.9.8+). No weird effects.
Let's resolve it worksforme.

Comment 33

[jlarsen]

Knowning that the w3c page had been changed I tested the attachments.
Ok, upon saving the 2 attachments to my harddrive the page looked fine upon
first glace but clicking anywhere in the area of the "Search W3C" area on the
bottom, caused the background of that area to go yellow, and nothing I could
find in the source or the css file suggested that should be the proper action.
Changing the summary to indicate we are talking about the attached file.
Note to testers, if you see no color anywhere (not even where it should be) you
may have to move the stylesheet and alter its link line, it didn't work for me
located as StyleSheets/home, but this is a win98 system, so you know..
2002021203

Comment 34

[jlarsen]

Attachment: The page with css working

The page with css working (changed the css ref to the bugzilla attachment)

Comment 35

[Brant Gurganus]

I can confirm.
2002030908/WinXP

The box (from CSS box model) surrounding the links in the navigation columns
change color when clicked.  I think the culprit CSS is:
td.navbar :active {
   background: #ffc;  <-- I think this should be #fea like the other colors.
   color: #900;
   text-decoration: none;
}

Comment 36

[jlarsen]

So we are doing the proper thing. Marking Fixed

Comment 37

[Kai Lahmann (is there, where MNG is)]

ok now