nsIWebBrowserFind.findNext fails because there is no primary shell for the document
brahmana
I am using nsIWebBrowserFind.findNext (from JS) and it always fails
with NS_ERROR_INVALID_POINTER. Here is the code snippet that I am
working with:
// this.browser is the <browser> associated with a tab, got by
gBrowser.getBrowserAtIndex(i)
var browserFind = this.browser.docShell.getInterface
(Ci.nsIWebBrowserFind);
if(browserFind)
{
browserFind.entireWord = true;
browserFind.matchCase = true;
browserFind.searchString = this.pageRequest.search[i].content;
contentMatchError = !browserFind.findNext();
}
I tried debugging into the FF code and it turns out that this is
happening because a document has not primary shell, as in
nsDocument::GetPrimaryShell() returns null, which is in turn because
of the mPresShells array being empty.
All this is in the content/layout code which I have no clue about. So
any help to resolve this is really appreciated.
Here is the stack trace:
nsDocument::GetPrimaryShell()
nsWebBrowserFind::GetFrameSelection(aWindow=0x06ccc978,
aSel=0x0012e880)
nsWebBrowserFind::SearchInFrame(aWindow=0x06ccc978, aWrapping=0,
aDidFind=0x0012ec3c)
nsWebBrowserFind::FindNext(outDidFind=0x0012ec3c)
NS_InvokeByIndex_P(that=0x055f2680, methodIndex=3, paramCount=1,
params=0x0012ec3c)
XPCWrappedNative::CallMethod(ccx={...}, mode=CALL_METHOD)
XPC_WN_CallMethod(cx=0x02c39340, obj=0x028010c0, argc=0,
argv=0x05492f7c, vp=0x0012ef00)
js_Invoke(cx=0x02c39340, argc=0, vp=0x05492f74, flags=2)
js_Interpret(cx=0x02c39340)
js_Invoke(cx=0x02c39340, argc=1, vp=0x05492e10, flags=0)
js_InternalInvoke(cx=0x02c39340, obj=0x04743780, fval=102438976,
flags=0, argc=1, argv=0x06d2d698, rval=0x0012f800)
JS_CallFunctionValue(cx=0x02c39340, obj=0x04743780, fval=102438976,
argc=1, argv=0x06d2d698, rval=0x0012f800)
nsJSContext::CallEventHandler(aTarget=0x02c41180, aScope=0x04743780,
aHandler=0x061b1840, aargv=0x06c0726c, arv=0x0012f8bc)
nsGlobalWindow::RunTimeout(aTimeout=0x06c7aa50)
nsGlobalWindow::TimerCallback(aTimer=0x06c7aac0, aClosure=0x06c7aa50)
nsTimerImpl::Fire()
nsTimerEvent::Run()
nsThread::ProcessNextEvent(mayWait=1, result=0x0012fa24)
NS_ProcessNextEvent_P(thread=0x00d7fcc8, mayWait=1)
nsBaseAppShell::Run()
nsAppStartup::Run()
XRE_main(argc=12, argv=0x00d7c098, aAppData=0x00d7cae8)
NS_internal_main(argc=12, argv=0x00d7c098)
wmain(argc=12, argv=0x00d794b0)
__tmainCRTStartup()
wmainCRTStartup()
Regards,
Srirang G Doddihal.
Boris Zbarsky
> I tried debugging into the FF code and it turns out that this is
> happening because a document has not primary shell, as in
> nsDocument::GetPrimaryShell() returns null, which is in turn because
> of the mPresShells array being empty.
OK. That's not an unexpected state of being for a document which is not
being shown (for example, which is loaded in a display:none iframe or
the like).
Do you have reason to believe there should in fact be a presshell here?
-Boris
brahmana
The URL loaded is http://www.google.co.in/ and from what I know the
document under discussion here is the content document loaded in the
tab. The page is properly loaded and I can see it. I call this findNext
() only after I get the load event. Is that good enough to expect a
presshell?
When this findNext call is made the browser can be in the background,
which in this case it was as I was debugging using VS. Is that the
problem?
-- Brahmana
Boris Zbarsky
> The URL loaded is http://www.google.co.in/ and from what I know the
> document under discussion here is the content document loaded in the
> tab. The page is properly loaded and I can see it. I call this findNext
> () only after I get the load event. Is that good enough to expect a
> presshell?
If you can see the content, there's a presshell.
> When this findNext call is made the browser can be in the background,
> which in this case it was as I was debugging using VS. Is that the
> problem?
That really shouldn't affect whether there's a presshell.
-Boris
brahmana
> If you can see the content, there's a presshell.
>
So what is resulting in an empty array here? Is this a bug? Will some
log data be useful?
I want to confirm that the document is the right one. Here is the
screenshot of the debugger : http://i46.tinypic.com/4g4x6r.png
The URL is highlighted by the blue box.
Apart from the regualar nsStandardURL there is also a second
nsSimpleURI (highlighted by the red box). What does this second one
refer to? Is this the actual document URI?
The source of page http://www.google.co.in/ indeed has an iframe with
display:none. Can this be causing the problem when the
nsIWebBrowserFind tries to search through child frames of the
document?
-- Brahmana
Boris Zbarsky
>> If you can see the content, there's a presshell.
>>
>
> So what is resulting in an empty array here?
Probably the fact that you're not actually calling GetPrimaryShell on
the document you're looking at.
> Is this a bug?
Doesn't sound like one so far.
> Will some log data be useful?
Not anything built-in.
> I want to confirm that the document is the right one. Here is the
> screenshot of the debugger : http://i46.tinypic.com/4g4x6r.png
...
> Apart from the regualar nsStandardURL there is also a second
> nsSimpleURI (highlighted by the red box). What does this second one
> refer to? Is this the actual document URI?
Yes, as the naming clearly says. The URL in the blue box is the base
URI for the given nested URI. The nested URI is almost certainly
about:blank, though it's hard to say for sure because you didn't expand
the nsSimpleURI part where the actual strings live.
> The source of page http://www.google.co.in/ indeed has an iframe with
> display:none. Can this be causing the problem when the
> nsIWebBrowserFind tries to search through child frames of the
> document?
Could be, sure. Certainly the document you're looking at here looks
like an about:blank document in a subframe of http://www.google.co.in/
(or opened from that page in some other way).
That said, "Find" in general deals with display:none iframes ok; I don't
know why it's not in your case.
-Boris
brahmana
>
> Could be, sure. Certainly the document you're looking at here looks
> like an about:blank document in a subframe ofhttp://www.google.co.in/
> (or opened from that page in some other way).
You are right. It is indeed about:blank.
>
> That said, "Find" in general deals with display:none iframes ok; I don't
> know why it's not in your case.
This is the code we are talking about:
http://mxr.mozilla.org/mozilla-central/source/embedding/components/find/src/nsWebBrowserFind.cpp#768
It invariably bails out if there is no presshell (as in a null pointer
returned for aSel because of no presshell).
Should that change? Or is there a better way to do this search?
-- Brahmana
Boris Zbarsky
> It invariably bails out if there is no presshell (as in a null pointer
> returned for aSel because of no presshell).
>
> Should that change? Or is there a better way to do this search?
If we can enter this code for display:none iframes, then whatever code
does that should probably not propagate this error return.
-Boris
brahmana
>
> If we can enter this code for display:none iframes, then whatever code
> does that should probably not propagate this error return.
>
Ok, so I see two things here:
1) Either we say we do not support searching through hidden frames, in
which case this error should not be propagated and we just move on to
the next frame.
2) If we want to support searching through the frames, then we need to
figure out if there is a way to get the selection without having a
presShell. Not sure if that really makes sense, but that is what
appears to be needed here.
If one of these is indeed right, then I will raise a bug.
May be we should do it the way regular Firefox search (type ahead
find) does it. It seems to handle this pretty well.
-- Brahmana
Boris Zbarsky
> 2) If we want to support searching through the frames, then we need to
> figure out if there is a way to get the selection without having a
> presShell.
There is no such way; selections are tied to presshells.
Since searching searches on the presentation, not the DOM, and since the
subframes in question have no presentation, there is no sane way to
search them.
> May be we should do it the way regular Firefox search (type ahead
> find) does it. It seems to handle this pretty well.
Yep.
-Boris