Closed
Bug 123385
Opened 24 years ago
Closed 5 years ago
Leaf Content Iterator
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
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?
| Assignee | ||
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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).
| Assignee | ||
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
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. :-)
| Assignee | ||
Comment 5•23 years ago
|
||
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
| Assignee | ||
Comment 6•23 years ago
|
||
[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
Updated•16 years ago
|
QA Contact: lchiang → traversal-range
Updated•13 years ago
|
Component: DOM: Traversal-Range → DOM: Core & HTML
Updated•5 years ago
|
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.
Description
•