488427 - nsIFind needs to call FlushPendingNotifications

Status: NEW

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

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

When nsIFind is used to search also within dynamically inserted content, the Find method always returns null (even if the searched text is there). 

Here is a scenario that describes the problem.

#1) The page, displays a list of expandable items. If an item is
expanded, its body is dynamically inserted into the page (just another
piece of HTML).

#2) The search should include current HTML on the page and also all
bodies that don't have to exist on the page (typically all items are
collapsed).

#3) If the search algorithm, finds out that the specified text is
within a body that is *not* currently displayed, the body (HTML) is
dynamically inserted (visually, the item is automatically expanded).

#4) The new created DOM is immediately used to create a DOM range and
passed to range-finder (nsIFind). But it always returns null even if
the text is there (I can see it on the page)...

If the step #4 is executed asynchronously, it works and the finder
returns proper range (nsIDOMRange). 


The possible workaround is to read "document.body.offsetWidth;" on the document in question between inserting the new DOM nodes and making the nsIFind call


According to the preceding discussion here:
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/02ddb42bd58af96c?hl=en#

...this means that nsIFind just needs to call FlushPendingNotifications in
the appropriate methods.

Comment 1

[Johnny Stenback (:jst)]

I'd love to see this for 1.9.2, but I don't think I'd hold the release for it.

Comment 2

[Justin Lebar (not reading bugmail)]

Attachment: Testcase

I'm having trouble reproducing this bug.  I've attached a mochitest testcase which works for me.  Could you have a look and let me know if this is different from what you're doing?

Comment 3

[David Zbarsky (:dzbarsky)]

Attachment: patch and test

I can't seem to reproduce the bug,  This test passes both with and without the patch. Can you check if this patch helps?

Comment 4

[Justin Lebar (not reading bugmail)]

Today is code freeze for 1.9.2, so I'm going to go ahead and mark this one as worksforme. If anyone can come up with a failing testcase or suggest how to change mine or David's so they fail, we can re-open this bug.

Comment 5

[Jonah Bishop]

This bug still bites me in Firefox 7.0.1. My extension, Googlebar Lite, uses the nsIFind interface to perform search term highlighting. If I don't use the workaround listed in the original poster's text, the nsIFind interface will skip to the end of the current DOM element, and go on to the next sibling element.

For example, assume that I have two paragraphs on a page, both of which have the word "Firefox" listed several times in each. Without the workaround, here's what happens:

1. The interface finds the first result in paragraph 1.
2. I surround said result with a styled span element.
3. I continue searching by calling nsIFind::Find() again. The second time around the loop, it has apparently skipped to paragraph 2 because the DOM has changed beneath its feet.

If I can find some time, I'll try to cook up a new test case. With my extension, I was able to consistently reproduce this before finding this workaround.

Comment 6

[Jonah Bishop]

Attachment: Test case illustrating the problem

This new test case illustrates the reported problem with nsIFind in Firefox. It takes a different approach from the previous test case, but illustrates what I believe is the same problem.

Comment 7

[Jonah Bishop]

I cannot seem to get the test case to work in browser now that it's posted here on Bugzilla, but it worked for me when saved as a local file on my system (using Firefox 7.0.1 on Windows XP). This is the first time I've posted a test case, so I may be missing something obvious. When I attempt to run it here on Bugzilla, I get the following error in my console:

Error: A script from "https://bug488427.bugzilla.mozilla.org" was denied UniversalXPConnect privileges.
Source file: https://bug488427.bugzilla.mozilla.org/attachment.cgi?id=565545
Line: 9

Long story short, if it doesn't work for you, save it locally and try it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, untrusted sites can't prompt for expanded privileges.

Comment 9

[Ralf Strobel]

I encountered the same behaviour in FF22, developing an extension similar to Jonah Bishop. The workaround also solved the problem for me. Tried to reproduce it today in FF23 but couldn't, so either I've screwed up or something must have changed.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 6 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.