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 to. 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 -> gerardok
QA Contact: janc → gerardok
Target Milestone: mozilla0.9.1 → mozilla0.9.2
See bug 77834. The fix for this will get rid of Session History's use of ContentID's.
Moving P2 and P3 bugs over to 0.9.3...
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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
16 years ago
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
16 years ago
Target Milestone: mozilla1.2alpha → Future
Aren't we removing content IDs altogether?
That's the idea.
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...
<http://lxr.mozilla.org/seamonkey/search?string=ContentId(> shows the following users: 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 relevant). 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 thing...
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 formcontrols?
We save state for other types of things too, unfortunately (eg scroll state).
15 years ago
Depends on: 166637
Content ids are no more (bug 166637).
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.