Content ID not updated on document switch

RESOLVED INVALID

Status

()

P2
normal
RESOLVED INVALID
18 years ago
13 years ago

People

(Reporter: hyatt, Assigned: hjtoi-bugzilla)

Tracking

Trunk
Future
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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 
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: petersen → janc

Updated

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
ContentID's.

Updated

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.

Updated

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...
<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).
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.