Using Mozilla 0.9. If you search for a quote (") in a page where you've used a <q> to quote text, the Find dialog will not find the quote. Mozilla also misses text generated by :after and :before. Minimal HTML / CSS example will be attached shortly. Not sure if XP App is the correct component.

Over to kin. No idea how we'll fix this.

This is sort of like looking for the bullet/number in a bullet/number list. They are rendered on screen, but they aren't in the content tree, so we don't find them. They're generated/anonymous content. Something like this probably won't happen till after 1.0.

Isn't this similar to http://bugzilla.mozilla.org/show_bug.cgi?id=72734? In that bug, generated content isn't selected for a cut and paste. Seems the same sort of thing, as this bug misses generated content in find.

Also, http://bugzilla.mozilla.org/show_bug.cgi?id=52109 is similar. Generated content is not picked up by :first-letter.

Just for the record, you also cannot select these quotes and they disappear on paste to, say, Emacs.

mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as qa contact. to find all bugspam pertaining to this, set your search string to "AppleSpongeCakeWithCaramelFrosting".

--> akkana (the new find-meister)

I'm using normal range iterators. I don't believe there's currently any way to iterate over normal and generated content together, or even any clear understanding of where generated content should come in the iteration order (since its position on the page may be different from its position in the tree). Joe, any insights? Marking future/helpwanted for now; if it turns out there is an iterator, or we get a clear idea how to write one, I can pull it in.

Kin points out that it is possible to get an iterator that traverses generated content: see the commented-out section near the beginning of nsSelection.cpp. Here's part of the comment: // Selection's use of generated content iterators has been turned off // temporarily since it bogs down selection in large documents. Using // generated content iterators is slower because it must resolve the style // for the content to find out if it has any before/after style, and it // increases the number of calls to GetPrimaryFrame() which is very expensive. (and there's a little more supporting detail) If it's so slow that the delay is noticable when making selections, imagine what this will do to find, which has to search through the entire tree. Please, let's not do this until/unless someone comes up with a way to make it reasonably fast. Note that Mozilla can't select the generated content either.

Please se also 12460.