384706 - [FIX]Searching text in xml pretty print doesn't work anymore

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Martijn Wargers (dead)]

To reproduce:
- Press Ctrl-F
- Search for "ab" for instance

It should find that text, but that doesn't happen anymore in current trunk builds.
This regressed on trunk between 2007-02-28 and 2007-03-01:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-28+04&maxdate=2007-03-01+08&cvsroot=%2Fcvsroot
I think a regression from bug 372086, somehow.
Note that this didn't work without problems, though, see bug 263049.

Comment 1

[[:Aleksej]]

Confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070617 Minefield/3.0a6pre

Comment 2

[Boris Zbarsky [:bzbarsky]]

Ugh.  Well, nsIFind assumes all find-related stuff can be represented as a DOM range.  That's not really true with anonymous content, and bug 372086 just enforces that invalid ranges are not created.

I guess we can just pass in nsIDOMRanges here that happen to not be nsRange...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Not working

No, that doesn't work either.  The find iterator uses standard content iterators which it tries to initialize with a "range" which has one endpoint in the native anonymous content (at a text node) and the other one at the root XML node (which is not anonymous inthis case).  This collapses to an empty range, so no finding happens.

So basically, either we need to rewrite find around the assumption that nsIRange cannot represent all possible ranges of interest, give up on find working with anonymous content, or back out bug 372086 (and accept the performance and security problems).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Or we could do this....

This basically makes the ranges used by find work the way they used to while everything else works the new way...

Comment 6

[Akkana Peck]

Nice! Any chance this might be wanted in other places as well? Like serializing the contents of a selection for a copy/paste?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Akkana, right now (on trunk) you can't even create a selection that spans across anonymous content boundaries (because selection works with ranges, and ranges can't express that).  We sort of want that -- for any non-temporary ranges, we don't want them spanning such boundaries as things stand.  See also bug 372470.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 268723 [details] [diff] [review]
Or we could do this....

>+      mSpanAnonymousSubtrees(PR_FALSE)

Please call this 'mMaySpanAnonymousSubtrees' since the bool means that the range is allowed to span anontrees, not that it actually does, right?

r/sr=me with that.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Checked in, with that change throughout.  Not sure how to write a test for this...  I guess it'd need some UniversalXPConnect and some search fu.