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




HTML: Parser
10 years ago
7 years ago


(Reporter: Kyle, Unassigned)


({regression, testcase})

regression, testcase
Bug Flags:
blocking1.9.1 -
blocking1.9.0.1 -
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)




(1 attachment)



10 years ago
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


10 years ago
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".
Regression range is
Caused by bug 311366 ?
Blocks: 311366
Component: General → HTML: Parser
Keywords: regression
Product: Firefox → Core
QA Contact: general → parser
Version: unspecified → Trunk
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?

Comment 3

10 years ago
Alright, the test case I used can be found at 

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:

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.

Comment 4

10 years ago
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?
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?

Comment 10

10 years ago
(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

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-
Created attachment 340282 [details]

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.
Keywords: testcase

Comment 13

10 years ago
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>

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>

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.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Flags: wanted1.9.2?
You need to log in before you can comment on or make changes to this bug.