Look ma! I just triggered a segfault in nsTypeAheadFind.cpp

[Jonathan Protzenko]

*tl;dr:* by moving the location of the FindToolbar DOM node in
Thunderbird, I managed to make the entire program crash in
nsTypeAheadFind.cpp:990

I'm trying to make Ctrl-F work with Thunderbird Conversations. I need to
move the FindBar to make it visible even when the Conversation View is
shown. Here's the DOM hierarchy:

<vbox>
<browser id="multimessage" /><!-- this is where the conversation view
lives -->
*<vbox>*
<hbox />
<hbox />
<deck />
<hbox>
<browser /><!-- this is where messages are usually displayed -->
</hbox>
<splitter />
<vbox />
*<findbar />*
</vbox>
</vbox>

When the conversation view is shown, the vbox in bold is hidden. Thus,
the findbar is hidden too. I decided to move the find bar as so, using
the DOM inspector.

<vbox>
<browser id="multimessage" /><!-- this is where the conversation view
lives -->
*<vbox>*
<hbox />
<hbox />
<deck />
<hbox>
<browser /><!-- this is where messages are usually displayed -->
</hbox>
<splitter />
<vbox />
</vbox>
*<findbar />*
</vbox>

I then change the findbar's browserid attribute to "multimessage",
summon the error console and run:

top.opener.document.getElementById("FindToolbar").onFindCommand()

As soon as I start typing something into the find bar, Thunderbird
segfaults brutally. I tried to read the code, and I think I should call
nsITypeAheadFind::SetDocShell somehow, but I can't seem to find the
nsITypeAheadFind instance associated to the <findbar>. Moreover, I
thought that changing the browserid attribute would do the trick since
it's what Thunderbird is doing already.

Even *without* changing the browserid attribute, it still segfaults.

I'm a little bit puzzled as to why changing the mere location of a DOM
node should make Thunderbird crash so badly. I'm really puzzled to any
help would be highly appreciated!

Thanks :),

jonathan

[Dave Townsend]

On 12/27/11 14:37, Jonathan Protzenko wrote:
> *tl;dr:* by moving the location of the FindToolbar DOM node in
> Thunderbird, I managed to make the entire program crash in
> nsTypeAheadFind.cpp:990

Do you have a crash report so we can look at the full stack of the crash?

[alta88[nntp]]

i do the same thing. in the overlay, there is:

<findbar id="FindToolbar" browserid="singlemessageContainer"/>

then in onload there is a 600ms delay timer (for other reasons), which
then does:

var findbar = document.getElementById("FindToolbar");
if (TM.u.winType == "mail:3pane" && findbar)
GetMessagePane().appendChild(findbar);

and there's been no problem with ctrl-f. it could be the browserid is
being changed too late, thus messing up those crazy 'pointers'.

[Jonathan Protzenko]

Thanks for all the hints.

After some more debugging, it turns out the crash goes away when *not*
using the DOM Inspector.

I still have the issue that the conversation view being made of
multiple iframes, the find code decides to only look into one of them
(the first one it encounters?) when searching...

(The structure is:

<browser id="multimessage">
<iframe type="content">
<!-- contents of message one -->
</iframe>
<iframe type="content">
<!-- contents of message two -->
</iframe>
...
</browser>
<findbar browserid="multimessage" />)

Cheers,

jonathan

(I can provide a full backtrace of the crash if needed, but since this
is linked to using the DOM Inspector, I don't think it's relevant
anymore).

> _______________________________________________
> dev-extensions mailing list
> dev-ext...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-extensions

[alta88[nntp]]

TotalMessage doesn't have that problem, find goes through all its
frames. but the structure is different, the <browser> loads an xhtml
page, which itself has a number of <frame>s. find looks in the document
of <browser>, where your <iframe>s are not, as they are just xul children.

long ago i decided against iframes but can't recall what the
showstoppers were.

[Jonathan Protzenko]

I'm not sure I understand what you mean. The <iframes> are in the
document of the <browser>, they're not in the XUL tree.

Maybe you could take a look at the issue? I've put my work in a branch
(see latest comment at
<https://github.com/protz/GMail-Conversation-View/issues/241>) so maybe
you could just try to see what's wrong :-).

Cheers,

jonathan

[alta88[nntp]]

the structure you posted is not actually the right representation. yes,
your <iframe>s are in the <browser> document. i can thus only surmise
that it's a difference between <frameset> <frame> and <iframe> in that
<iframe> could be hardcoded for exclusion. it could be in nsIFind or in
whatever cares about appType=mail or in gecko land.

i don't know why <iframe> doesn't work, i just know what does ;)

[Neil]

Jonathan Protzenko wrote:

> (I can provide a full backtrace of the crash if needed, but since this
> is linked to using the DOM Inspector, I don't think it's relevant
> anymore).

DOM Inspector is 100% JavaScript. While it might be making your crash
easier to trigger, it can't be responsible for it, so a stack trace
would still be helpful.

--
Warning: May contain traces of nuts.

[Gijs Kruitbosch]

On 29/12/2011 01:42 AM, Neil wrote:
> Jonathan Protzenko wrote:
>
>> (I can provide a full backtrace of the crash if needed, but since this is
>> linked to using the DOM Inspector, I don't think it's relevant anymore).
>
> DOM Inspector is 100% JavaScript. While it might be making your crash easier to
> trigger, it can't be responsible for it, so a stack trace would still be helpful.

Did the magic red-box-highlight-square and the DOM treewalker code move out of
native code? It's been a long time since I looked, and it's been broken whenever
I've looked for the result of that code on my beta Fx builds, but still, that at
least used to be native rather than JS...

Gijs

[Neil]

Well, that depends on how you blur the native code distinction... just
creating a window involves oodles of native code. It's true that there
are some components bundled with XULRunner that are typically only used
by DOM Inspector, but then again there is a component that is typically
only used by the find bar.