Bug 205499

This also affects Listen.
It segfaults each time, it loads a gtkmozembed widget, just try by clicking on
wikipedia or Lyrics tabs.

Forwarded this bug upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=370767

Tracked it down to this:

EmbedPrivate::Realize (this=0x8cd8fc8, aAlreadyRealized=0xbfd3b2f8)
    at embedding/browser/gtk/src/EmbedPrivate.cpp:257
257       mNavigation->SetSessionHistory(mSessionHistory);

mNavigation is NULL, as is mSessionHistory, dereferencing mNavigationHistory is
the cause of the segmentation fault.

webBrowser is NULL and I suspect that is the root cause of the other NULL
pointers. webBrowser looks like it's initialized a couple of lines up with this:

mWindow->GetWebBrowser(getter_AddRefs(webBrowser));

(gdb) p mWindow
$8 = (class EmbedWindow *) 0x8cf6ed0

so it looks like GetWebBrowser is failing and no one is checking the results.

it looks like GetWebBrowser is returning its mWebBrowser
(gdb) p mWindow.mWebBrowser
$13 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}

which is NULL, I'm going to make a guess mWebBrowser is initialized here:
nsresult
EmbedWindow::Init(EmbedPrivate *aOwner)
{
  // save our owner for later
  mOwner = aOwner;

  // create our nsIWebBrowser object and set up some basic defaults.
  mWebBrowser = do_CreateInstance(NS_WEBBROWSER_CONTRACTID);
  if (!mWebBrowser)
    return NS_ERROR_FAILURE;

  mWebBrowser->SetContainerWindow(NS_STATIC_CAST(nsIWebBrowserChrome *, this));
  
  nsCOMPtr<nsIDocShellTreeItem> item = do_QueryInterface(mWebBrowser);
  item->SetItemType(nsIDocShellTreeItem::typeContentWrapper);

  return NS_OK;
}

That's as far as I've gotten, feel free to jump in if you know more about this
code than I do.

FWIW, the test program TestGtkEmbed fails exactly the same way, thus the failure
does not seem to have anything to do with the python binding.

Looks like these upstream bugs are relevant:

https://bugzilla.mozilla.org/show_bug.cgi?id=358926
https://bugzilla.mozilla.org/show_bug.cgi?id=358923

Based on the above comments, I'm reassigning this to firefox.

adding this to the example makes it work

comp_path='/usr/lib/firefox-1.5.0.7'
gtkmozembed.set_comp_path(comp_path)

FWIW, when googling gtkmozembed issue I found several recommendations that
set_comp_path was a necessary prerequisite for making gtkmozembed work. Unless
there is a query to get the comp path (is there? I didn't find one) then I don't
see how this is going to work with deployed software. How are we going to know
what the comp path is on any given machine?

Isn't this something which should be handled internally in the library? It seems
like it used to be because prior to FC6 the gtkmozembed example and test
programs worked, but now they fail. What changed? Why can't the mozilla/firefox
libraries find their own loadable modules?

perhaps the python bindings needed to export something akin to get_comp_path by
calling GRE_GetGREPathWithProperties() as documented here:
http://developer.mozilla.org/en/docs/GRE

The TestGtkEmbed program should probably be calling
GRE_GetGREPathWithProperties() and then setting the component path based on the
results of the query.

Sound right?

*** Bug 300881 has been marked as a duplicate of this bug. ***

We just updated the Firefox version in Fedora/development from 2.0 to a 3.0
pre-release version, which improves performance, memory usage, and fixes many
bugs and crashes.

Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is
in.  If this bug is still present in rawhide using a Firefox 3.0 version, please
re-open this bug.

Thanks and Happy Holidays

For anyone who finds this while looking for solutions to gtkmozembed crashing, the answer is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=358926#c5

gecko embedding requirements include someone telling gecko where to find the libraries they want used. classically this is handled by (running your application through) run-mozilla.sh.