Closed Bug 439646 Opened 16 years ago Closed 14 years ago

While incorporating Navigation via javascript, "body bg=#" function is ignored

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: kipponoui, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

testcase
426 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

A mouseover of the table on the left side of the screen ("NavBar") pulls out a Navigation menu for the site.  However, mousing over the words "Navigation", "Affiliates", or "NavBar" (once the Navigation window is already opened) causes the background color to be ignored, and the default (white) set in place.

Reproducible: Always

Steps to Reproduce:
1.go to http://www.freewebs.com/kipponoui
2.mouseover the "NavBar"
3.place mouse over the words "Navigation", "Affiliates", or "NavBar"
Actual Results:  
The table background colors can be seen, but not the body background.

Expected Results:  
The background body color should have remained at "#595959"

refreshing the page reloads the <body bg=> function.  Javascript used for the NavBar can be found at http://www.dynamicdrive.com/dynamicindex1/davidmenu.htm
Severity: minor → normal
OS: Mac OS X → All
Hardware: Macintosh → All
Can you provide a testcase, it's kind of hard to really understand the script.

I do see however that once you roll over one of the above-mentioned items, body.bgcolor is set to "white".
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
Alright, the test case I used can be found at 
http://www.freewebs.com/kipponoui/testcase.html

Right click -> View Page Source is (obviously) left enabled.  The freewebs bar at the bottom is an auto add, designed by freewebs. If you look at the script directly above the "</body>" tag, you can see that it's a tracker script.  Again, this is automatically added by freewebs.

Looking at the code, it can be seen that two javascript files are called upon on page load, in the head section: "ssm.js" and "ssmItems.js"  Both of these code files can be found at:
http://www.freewebs.com/kipponoui/ssm.js
http://www.freewebs.com/kipponoui/ssmItems.js


The problem still persists, even after removing both the content of the page and the style sheets.  If you need anything else, don't hesitate to ask.
Looking at the "ssmItems.js" file, I believe that the "linkOverBGColor" tag "leaks" over to the body.bgcolor function.  Thus, when "linkOverBGColor" is not being called upon, body.bgcolor has no specification and reverts to default, or "white".
>Looking at the "ssmItems.js" file, I believe that the "linkOverBGColor" tag
>"leaks" over to the body.bgcolor function.
Which body.bgcolor function? couldn't find any in the script.

Am I missing something here, I can't seem to find any calls to body.bgcolor or to body.style.background[Color]! The summary is pretty vague, what does 'while navigating' mean exactly, and I couldn't find anything that changes the body background color besides in the js for the bottom banner which, from what I understood, is put there by the site host and is done at the start, not when the menu is pulled out, unless something there is getting effected through namespace collision.:/
Alright, got it.

The script changes the bgColor of the tds in mousover mouseout functions as follows: onmouseover="bgColor=..." and doesn't use "this.bgColor=...", so that's where the bug comes from. If you add this.bgColor the problem is fixed.

That's why it changes the body bgColor.;)
So is this INVALID/WFM?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Well it's not exactly what the report says, but it is a bug in that a "bgcolor = " in the onmouseover handler changes the node and the body bgcolor.
There was someone in #js who was getting confused or bitten by events bubbling differently than expected. Did we change bubbling behavior between Firefox 2 and 3?
(In reply to comment #9)
> Did we change bubbling behavior between Firefox 2 and 3?
Event propagation works now per DOM Events spec; event target chain
is created before event dispatch. And also focus and blur are now handled per the
spec.


Not going to block on this based on what's easily extractable from this bug. If there's really a problem here still, please *attach* a testcase (don't link to it) showing the problem.
Flags: blocking1.9.1? → blocking1.9.1-
Attached file testcase — 
This is the behavior the reporter was observing, the subject doesn't exactly reflect this... I'm not entirely sure this is a bug though.
The unmodified script from Dynamic Drive writes the following HTML (unimportant parts stripped):

<TD BGCOLOR="red" onmouseover="bgColor='blue'" onmouseout="bgColor='red'">
<ILAYER><LAYER onmouseover="bgColor='blue'" onmouseout="bgColor='red'">
<DIV>Some Text</DIV>
</DIV></LAYER></ILAYER></TD>

Now, back in ancient times Netscape 4's layer elements actually had a bgColor attribute, so this ended up setting the bgColor of both the layer and the td. Nowadays, layer is just another custom element, so this actually sets the TD's bgColor and document.bgColor. I guess bug 311366 exposed this problem because before it was fixed either layer or ilayer wasn't allowed to contain DIV, so the DOM tree looked like this:

<TD BGCOLOR="red" onmouseover="bgColor='blue'" onmouseout="bgColor='red'">
<ILAYER><LAYER onmouseover="bgColor='blue'" onmouseout="bgColor='red'"></LAYER></ILAYER>
<DIV>Some Text</DIV>
</TD>

In other words, the layer was empty, so it was impossible to hover over it and trigger the event. I'd recommend to mark this bug invalid and chalk it up as yet another poor effort from Dynamic Drive.
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Flags: wanted1.9.2?
I don't see a parser bug here.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Flags: wanted1.9.2?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: