341586 - Inspecting event.target when monitoring DOMNodeInserted events breaks UI

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Anthony Lieuallen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

With an extension I wrote, a user complained of many other extensions'
status-bar items as disappearing after installing it.  A reduced test case of the offending code is:

function flagInsertedElement(event) {
	var el=event.target;
}
document.addEventListener('DOMNodeInserted', flagInsertedElement, false);

When the line referring to "event.target" is removed, the symptoms disappear.

Reproducible: Always

Steps to Reproduce:
1. Create and use a new, empty, Firefox profile
2. Right click on the toolbar, choose Customize
3. Move a default element and/or add a non custom one to the display
4. Install the attached extension
Actual Results:  
UI customizations fail after step 4.  Things are generally missing, if added,
and in default locations if moved.

Expected Results:  
With this test case code, nothing.

Comment 1

[Anthony Lieuallen]

Attachment: Extension containing the test case code

Comment 2

[Anthony Lieuallen]

Bug DOES happen in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

Bug does NOT happen in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060614 Minefield/3.0a1

Comment 3

[Martijn Wargers (dead)]

So this is already fixed somehow?

Comment 4

[Anthony Lieuallen]

> So this is already fixed somehow?

From the UA strings, it would appear that yes it is, in Gecko 1.9.
But not in Firefox 1.5 or 2.0 (BonEcho), both using Gecko 1.8.

Comment 5

[Martijn Wargers (dead)]

Well, in that case this bug is worksforme. It is already fixed on trunk, somehow.

Comment 6

[Anthony Lieuallen]

Is there no chance of finding the fix and back porting it?  3.0 is quite some time to wait.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Need to really first understand what is the problem.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

er, need to understand what is causing the problem 

Comment 9

[Martijn Wargers (dead)]

Well, finding in what time period this was fixed might be useful.
You can find here an archive of old Firefox trunk builds if you want to find out:
http://archive.mozilla.org/pub/firefox/nightly/
However, if this was fixed on trunk, there was probably already debated whether the patch was safe for branch.

Comment 10

[Anthony Lieuallen]

I've narrowed it down to this:

FAIL: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1
OK: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060602 Minefield/3.0a1

Comment 11

[Martijn Wargers (dead)]

Ok, from that range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-06-01+05&maxdate=2006-06-02+10&cvsroot=%2Fcvsroot

It appears that bug 90983 should have fixed this.
You might want to add a comment in that bug, explaining you want it on the 1.8.1 branch and why you want it on the 1.8.1 branch.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If someone is interested in backporting that patch then they'll have to do it themselfs as it involves some work that I won't have time for.

However, that patch simply makes us not send out mutation events for parsed content, which only seems to wallpaper the problem described here. If someone were to modify the DOM the mutation events would still be fired and the problem would show itself.