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

RESOLVED FIXED

Status

()

Core
DOM: Events
RESOLVED FIXED
14 years ago
12 years ago

People

(Reporter: Martin Honnen, Assigned: smaug)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 133934 [details]
test case (reports DOMAttrModified events in a debug window opened with window.open)

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)

Comment 3

13 years ago
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.

Created attachment 229943 [details] [diff] [review]
Set anonymous bit always for event handling

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
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.