Closed Bug 223393 Opened 21 years ago Closed 18 years ago

strange DOMAttrModified mutation events fired on HTMLHtmlElement while page loads (anonymous content)

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martin.honnen, Assigned: smaug)

Details

Attachments

(2 files)

test case (reports DOMAttrModified events in a debug window opened with window.open)
1.51 KB, text/html
Details
Set anonymous bit always for event handling
6.72 KB, patch
sicking
: review+
sicking
: superreview+
Details | Diff | Splinter Review 
Strange DOMAttrModified events are fired on the HTMLHtmlElement (the root
element) while a HTML page loads. 
The attribute names reported are sborient and orient which are not any HTML
attributes, I suspect some XUL stuff propagates up but that shouldn't happen.
Tested with Mozilla 1.5 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)
Gecko/20031007). It also occurs with Netscape 7.1 (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)).
I will attach a test case that demonstrates the problem.
You will see events like

DOMAttrModified: evt.target: [object HTMLHtmlElement]; evt.relatedNode: [object
Attr]; evt.attrName: sborient; evt.prevValue: ; evt.newValue: horizontal;
evt.attrChange: addition;

and

DOMAttrModified: evt.target: [object HTMLHtmlElement]; evt.relatedNode: [object
Attr]; evt.attrName: orient; evt.prevValue: ; evt.newValue: horizontal;
evt.attrChange: addition;

reported in the debug window.
Hm, we should definitely prevent mutation events from anonymous scrollbar
elements from reaching the document.  Perhaps we should also suppress mutation
event firing until onload fires, if we aren't already.
Summary: strange DOMAttrModified events fired on HTMLHtmlElement while page loads → strange DOMAttrModified mutation events fired on HTMLHtmlElement while page loads (anonymous content)
Mutation events could have native browser events (XUL or otherwise), this could
be useful for determining non-standard properties. This should either be
intentionally included or should be cleaned up.

Mutation events should definitely not be blocked from firing before onload. See
the example, which should fire before the page has loaded:


========================================================
<body>
<script>
document.addEventListener('DOMAttrModified', function(e) {alert(e.newValue); },
false);

document.bgColor = "tan";
</script>
... more document here

========================================================

Now, if anyone wants to add mutation events onload, they can just do it by using
a load event listener to attach the mutation event.

window.addEventListener("load", addMutationListeners, false);
Does this still happen? I think bug 328885 fixed this.
(In reply to comment #4)
> Does this still happen? I think bug 328885 fixed this.

I still see various domattrmodified events fired with the testcase for native anonymous elements.


Because XUL doesn't handle native anonymous properly, we need to have a separate
bit for event handling.
Assignee: events → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #229943 - Flags: superreview?(bugmail)
Attachment #229943 - Flags: review?(bugmail)
Comment on attachment 229943 [details] [diff] [review]
Set anonymous bit always for event handling

looks good. r/sr=me
Attachment #229943 - Flags: superreview?(bugmail)
Attachment #229943 - Flags: superreview+
Attachment #229943 - Flags: review?(bugmail)
Attachment #229943 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: