Content ID not updated on document switch




18 years ago
13 years ago


(Reporter: hyatt, Assigned: hjtoi-bugzilla)


Windows 98

Firefox Tracking Flags

(Not tracked)




18 years ago
Content elements are not obtaining a fresh content ID when transferred to a new 
document (or when placed into a document for the first time).

The particular problem I ran into was CloneNode.  Cloned nodes are not in the 
document when cloned, and so they don't have content IDs.  Upon insertion into 
the document, you would expect them to get content IDs, but they don't appear 

I also noticed content IDs being assigned in CreateELementNS.  This seems 
fragile and incorrect to me, since you're relying on the element eventually 
being inserted into the same document that did the creation.

IMO the patch here is to remove the SetContentID from CreateElement 
implementations and to add a SetContentID call to SetDocument in nsXULElement 
and nsGenericElement.  This ensures that content IDs properly update when the 
node enters a new document.
QA Contact: petersen → janc


18 years ago
Target Milestone: --- → mozilla0.9.1

Comment 1

18 years ago
QA Contact -> gerardok
QA Contact: janc → gerardok

Comment 2

18 years ago
-> 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 3

18 years ago
See bug 77834.  The fix for this will get rid of Session History's use of


17 years ago
Priority: P3 → P2

Comment 4

17 years ago
Moving P2 and P3 bugs over to 0.9.3...
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 5

17 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 6

17 years ago
Bulk re-assign of my 0.9.4 bugs to Heikki.  I will not have the cycles to work
on these bugs while Clayton is on sabbatical for the next six weeks.
Assignee: nisheeth → heikki
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → Future
Aren't we removing content IDs altogether?
That's the idea.


16 years ago
QA Contact: gerardok → stummala
So... does anything other than accessibility use the content ID?  I don't
believe anything does.... if so, could it possibly use some other mechanism?
The form submission code used to use it too, does it not any more?

I'd really really love to see mContentID go away, accessibility just needs a
unique id, i.e. the pointer value, so that's trivial to change...
<> shows the following

1) nsContentUtils::GenerateStateKey.  This uses the content id to detect
   anonymous content.  There are better ways (imo we could just add a
   IsAnonymous() method on nsIContent that would return IsNativeAnonymous() ||
   GetBindingParent().  Or just have callers do the "or" themselves....  We also
   have people detecting anonymous content using IndexOf, which works even for
   text anonymous content.... but for form controls that should not be
2) nsAccessNodeWrap::get_nodeInfo

That's it, as far as I can tell.
nsContentUtils::GenerateStateKey() does more with contentID than check if a node
is anonymous, look further down, it's part of the key in session history... Did
someone say XPath?
Hmm, yeah.  It's used in the "not html document or not form control" code....

XPath would definitely be better.  ccing some people who know about that sort of
Not sure we can use XPath since transformiix is an optional component (minimo
doesn't include it for example). But it should definitly be possible to figure
something out.

Could we maybe just keep a content-id in formcontrols? I.e. let the document
keep the counter that counts all created elements, but only put the member in
We save state for other types of things too, unfortunately (eg scroll state).
Content ids are no more (bug 166637).
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.