301655 - Invalid state of WebBrowserFind with frame

Status: RESOLVED WORKSFORME

(Toolkit :: Find Toolbar, defect)

Description

[Georges-Etienne Legendre]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Using this code allow to find the word "word" in page :

var finder = window.getBrowser().webBrowserFind;
finder.searchString = "word";
finder.findNext();

This code throws this exception under certain circumstances :
Exception... "Component returned failure code: 0xc1f30001
(NS_ERROR_NOT_INITIALIZED) [nsIWebBrowserFind.findNext]"  nsresult: "0xc1f30001
(NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
chrome://searchwp/content/termsToolbar.js :: anonymous :: line 73"  data: no

Reproducible: Always

Steps to Reproduce:
Please use the test case joined to this bug.
1. Execute the code above 3 times: this allows to find the word "word" located
in the iframe.
2. Refresh the page (F5)
3. Execute the code above 1 time. The given exception occurs.

Actual Results:  
At the step 3, the word "word" isn't find.

Expected Results:  
We should be able to find the next word "word" (in this case, the first one agin).

Comment 1

[Georges-Etienne Legendre]

Attachment: Html Testcase

Comment 2

[Martijn Wargers (dead)]

Works for me with current trunk build. Please test again with a nightly trunk build:
http://ftp.scarlet.be/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 3

[Georges-Etienne Legendre]

I have the same problem with the latest trunk (2005-08-07). How did you test it?
(How did you execute the javascript)

Comment 4

[Martijn Wargers (dead)]

Attachment: iframe needed for testcase

Comment 5

[Martijn Wargers (dead)]

Attachment: Testcase

Because this testcase needs enhanced privileges, you need to test it locally.
With this testcase, I still can't reproduce the bug, by using the steps
described in comment 0.

Comment 6

[Georges-Etienne Legendre]

You're right, with this test case it works.

I use this code in my extension and this code is called from a toolbar button.

Comment 7

[Georges-Etienne Legendre]

Attachment: A testcase extension

Here is a testcase extension to use with the testcase from comment 5. Go to
Toolbar > Customize to add the button.

Comment 8

[Martijn Wargers (dead)]

Ok, I see the bug now, but I get this error:
Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIWebBrowserFind.findNext]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://browser/content/browser.xul :: oncommand :: line 1"  data: no]

Comment 9

[Martijn Wargers (dead)]

According to the idl, nsIWebBrowserFind should not even find inside iframes:
http://lxr.mozilla.org/seamonkey/source/embedding/components/find/public/nsIWebBrowserFind.idl#48

So you'll probably need nsIWebBrowserFindInFrames anyway.
You can find some example code here:
http://lxr.mozilla.org/seamonkey/source/toolkit/content/findUtils.js#65

Comment 10

[Georges-Etienne Legendre]

(In reply to comment #8)
> Ok, I see the bug now, but I get this error:
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80004005 (NS_ERROR_FAILURE) [nsIWebBrowserFind.findNext]"  nsresult:
> "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
> chrome://browser/content/browser.xul :: oncommand :: line 1"  data: no]

You're right.

I'll try to use nsIWebBrowserFindInFrames instead, but anyway, there is a
problem with nsIWebBrowserFind.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So what, exactly, is the bug here, then?

Comment 12

[Martijn Wargers (dead)]

Sorry, comment 9 is wrong, looking at:
http://lxr.mozilla.org/seamonkey/source/embedding/components/find/public/nsIWebBrowserFind.idl#48
"It does not by default search subframes or iframes. To change this behaviour, and to explicitly set the frame to search, QueryInterface to nsIWebBrowserFindInFrames."

But then later in the code:
"searchFrames
 Whether to search through all frames in the content area. Default is true."

So there seems to be something wrong with the documentation wrong here.


This bug can still be reproduced, when installing the extension and following the steps in comment 0. (I haven't been able yet to get the bug in a non-extension environment).

Comment 13

[Martijn Wargers (dead)]

Attachment: testcase2

Ok, with this testcase, you can see the bug. You need to test it locally, because of enableprivilege stuff.
Follow the steps in the testcase to trigger the bug.

I guess, this testcase is analogous to the code here:
http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/browser.xml#233
where nsIWebBrowserFind is a cached value.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Neil, do you know anything about this code?

Comment 15

[[e-mail]]

Not really, nor can I reproduce it (note that trying to run it from file gave me a DOM security error so I enabled privileges and ran it from bmo instead).

Comment 16

[Georges-Etienne Legendre]

I also get this error when I search "vc" on this page (search it a couple of time): http://www.codeproject.com/dll/ctovbarray_passing.asp

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIWebBrowserFind.findNext]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://searchwp/content/termsToolbar.js :: anonymous :: line 85"  data: no]

Maybe it is releated?

Comment 17

[[:Aleksej]]

Any updates on this bug? Can it still be reproduced?

Comment 18

[Martijn Wargers (dead)]

I can't reproduce it with my testcase anymore, I think.
Reporter, can you still reproduce this bug with the current nightly trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 19

[Martijn Wargers (dead)]

And can you reproduce what you see in comment 16, still in the nightly trunk build?

Comment 20

[Graeme McCutcheon [:graememcc]]

Attachment: Testcase Dec 07

Comment 21

[Graeme McCutcheon [:graememcc]]

Original reporter:

Your expected behaviour can be achieved by adding the line:
finder.wrapFind = true;

This will cause nsWebBrowserFind to wrap back to starting point, and find the first occurrence of "word" again.

That said, as noted in the discussion, there seems to be a problem in the case where wrapFind = false.

I xperienced the problem with NS_ERROR_FAILURE on page reloads. (User agent : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007121009 Minefield/3.0b2pre Build ID: 2007121009)

Using the testcase I have submitted (Testcase Dec 07) and loading the page bug301655.html locally, and elevating priveleges when prompted, if, as per original reporters reproduction instructions, you click the button 3 times, and reload the page, clicking the button will result in nsWebFinder returning NS_ERROR_FAILURE.

However, I found that reloading the page once more resulted in "expected" behaviour resuming. In fact, by repeatedly reloading, I see an alternating pattern of Expected behaviour / NS_ERROR_FAILUREs.

With wrapFind = true, I could happily reload as many times as I wanted with no errors.

I don't know enough about XPConnect/XPCOM to say whether this could be caused by  some memory leak pattern, or if this results from usage of nsWebFinder in a way  that was not intended.

dbaron: because of this, I have cc'd you in on this bug - as author of the "how to find leaks in xpcom" I thought you would be able to answer that point. Apologies if this was incorrect.

Comment 22

[Tyler Downer [He/Him]]

Reporter, if you can still see this, please reopen and mark it against the version of Firefox you tested with. Thanks.

Comment 23

[Martijn Wargers (dead)]

The testcase from comment 20, https://bugzilla.mozilla.org/attachment.cgi?id=293325 seems to work now, as the testcase2 from comment 13.

I'm still seeing the NS_ERROR_INVALID_POINTER errors occuring under certain circumstances. I'll file a new bug for that.

Tyler, this bug is not INCOMPLETE, since the bug contained testcases that could reproduce the bug in question. So I'm marking it WORKSFORME.

Comment 24

[Martijn Wargers (dead)]

I've filed bug 623494 for the NS_ERROR_INVALID_POINTER error, that I'm seeing.