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 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1205489040&maxdate=1205516400&cvsroot=%2Fcvsroot Caused by bug 311366 ?
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser
Version: unspecified → Trunk
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
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-
Created attachment 340282 [details] 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-
I don't see a parser bug here.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.