Closed Bug 123385 Opened 24 years ago Closed 5 years ago

Leaf Content Iterator

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED INACTIVE
mozilla1.4beta

People

(Reporter: mozeditor, Assigned: mozeditor)

Details

The Find code would be simplified by having a version of the content iterator that visited only leaf nodes (nodes that have no children). Other folks have occassional asked for this as well so I think it is worth having. You could simply use the regualar iterator and ignore non-leaves, but I beleive we can leverage the performance work in the iterator to get a speed gain in a pure leaf iterator. Not sure what component my content iteraotr stuff falls under. DOM Traversal-Range?
putting on 1.1 list. We can move it up if Akkana concludes we need it for Find performance.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Actually: just yesterday I realized that I do need to do my skipped content check after all (which had been commented out due to lack of a bidi iterator). I've put in some temporary code that climbs up the parent chain for each node to see if a parent is in the skipped list, but I don't know how this affects performance and if we're worried about performance, the leaf iterator (or even just the regular iterator but being able to use both pre and post order) would help ... If it helps, I can get some numbers on how climbing up the parent chain affects performance. I'm not sure how expensive GetParent is (seems like it should be fairly cheap, but I thought that about GetNextSibling and I was dead wrong).
GetParent is cheap. And you will still have to make GetParent calls each time even with a leaf iterator, if you want to check for block crossings.
Two things I need the iterator to do: 1. Visit parent nodes both on the way in and on the way out. (This would also help in detecting crossing block borders during copy/serialization). 2. Offer a PositionAt or equivalent which takes a node, not a content. Not all nodes can QI to nsIContent, but the selection can be placed at such nodes so I need to be able to iterate starting there. I'm not sure if "leaf content iterator" is really the best name for what I want, since it seems to contradict both of the goals. :-)
The days of having a half dozen milestones out in front of us to divide bugs between seem to be gone, though I dont know why. Lumping everything together as far out as I can. I'll pull back things that I am working on as I go.
Target Milestone: mozilla1.1alpha → mozilla1.2beta
[ushing these out as far as bugzilla will let me. I'll pull them back as I work on them.
Target Milestone: mozilla1.2beta → mozilla1.4beta
QA Contact: lchiang → traversal-range
Component: DOM: Traversal-Range → DOM: Core & HTML
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.