If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Inspecting event.target when monitoring DOMNodeInserted events breaks UI




DOM: Events
11 years ago
11 years ago


(Reporter: Anthony Lieuallen, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)



(1 attachment)



11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060508 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060508 Firefox/

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

11 years ago
Created attachment 225655 [details]
Extension containing the test case code

Comment 2

11 years ago
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
So this is already fixed somehow?

Comment 4

11 years ago
> 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.
Well, in that case this bug is worksforme. It is already fixed on trunk, somehow.
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Comment 6

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

Comment 7

11 years ago
Need to really first understand what is the problem.

Comment 8

11 years ago
er, need to understand what is causing the problem 
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:
However, if this was fixed on trunk, there was probably already debated whether the patch was safe for branch.

Comment 10

11 years ago
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
Ok, from that range:

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.
Depends on: 90983
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.
You need to log in before you can comment on or make changes to this bug.