GNOME Bugzilla – Bug 535127
ephy component registration sometimes lost at runtime
Last modified: 2009-08-07 23:34:53 UTC
Sometimes, the following happens: - ephy seems to lose history. Going to a page I know I have visited links on, all links are shown as unvisited. Links newly visited afterwards DO show up as visited. - (this is with about:config tweaks to ask befores allowing a page to set/change a cookie) on loading a page in a new tab (background), ephy switches to the new page on its own, but no modal dialogue is shown. Afterwards, tabs cannot be closed anymore, selecting text with the mouse doesn't work anymore in any tabs, and loading seems to never terminate. Attaching gdb, the stack looks like this: [...]
+ Trace 198779
So it's showing the modal cookie dialogue, but it's not visible. Note that it's calling gecko's XUL implementation of the cookie prompt, NOT our own implementation of it! Analysis: It seems that somehow, components were re-registered, wiping out our overridden registered contract IDs.
Haven't seen this since using the 2.22.2 with xulrunner 1.9 rc2; closing.
Still happening.
*** Bug 545488 has been marked as a duplicate of this bug. ***
*** Bug 547854 has been marked as a duplicate of this bug. ***
This also manifests itself as the firefox 3 style download window appearing instead of Epiphany's own one. But this only happens (for me) on amd64.
I should note that I am using 2.22.3.
I'm now seeing this on my i386 system too.
(In reply to comment #7) > I'm now seeing this on my i386 system too. I've seen this once as well on i386, but cannot reproduce...
*** Bug 549270 has been marked as a duplicate of this bug. ***
In case that’s useful for someone, Sam added a full trace with NSPR logging to the downstream report (http://bugs.debian.org/494058). My current guess is that the recent nsNavHistory changes actually work around this problem, except for the download window issue. For this one, I suspect this can only happen right after an upgrade, but that hasn’t been confirmed yet.
(In reply to comment #10) > My current guess is that the recent nsNavHistory changes actually work around > this problem, except for the download window issue. For this one, I suspect > this can only happen right after an upgrade, but that hasn’t been confirmed > yet. When I saw that problem with the downloader once, I hadn't upgraded recently. It seems you have some theory why this thing happens, can you share it?
Reality check.
*** Bug 580681 has been marked as a duplicate of this bug. ***
I'm getting this behaviour more and more, it seems to be triggered easily with latest xulrunner 1.9.0.11 (and 1.9.0.10). Go to one of your own photo page on flickr and press "Delete" button in the webpage : you won't get the modal dialog for confirmation and many actions in Epiphany (closing a tab) will be disabled.
I'm seeing this frequently on both i386 and AMD64, ephy 2.26.1 from Debian unstable.
I'm sorry to inform you that there will be no more fixes for the Gecko backend of Epiphany, as we have switched to WebKit. Marking OBSOLETE.
This seems to be a combination of two bugs; 1: Chrome windows aren't handled correctly with gtkmozembed 2: Components get de-registered at some point during runtime 1, I've fixed in the headless backend a while ago. I'll see about back-porting this, filing a bug upstream and attaching a patch. Pretty poor form that I haven't done this already, sorry about that. 2, No idea, but if I get the time, I'll see if I can duplicate and debug it (no promises on that though). It's odd that I've not seen the same thing using the headless backend, but I've made some reasonably significant changes and we use it in a different way that maybe we don't trigger the same bug. I'll report back here on any progress made.
https://bugzilla.mozilla.org/show_bug.cgi?id=509046 - This is the upstream bug I've filed for the first issue, along with a patch that fixes it. If anyone is still interested in this bug and would like to see the 2nd bit fixed, please say. Reliable reproduction steps/instructions on building Epiphany/etc. would all be appreciated (I don't have much time to look into this and I don't actually use Epiphany or gtkmozembed...)
Just a note, although this will stop lock-ups, gtk-mozembed users still need patching. When responding to the 'new-window' signal of GtkMozEmbed, instead of: embed = gtk_moz_embed_new (); ... some code that causes widget realization... ... gtk_moz_embed_set_chromemask (embed, chromeflags); ================== You should now do: ================== embed = gtk_moz_embed_new_with_chrome (chromeflags); ... ================== or ================== embed = gtk_moz_embed_new (); gtk_moz_embed_set_chromemask (embed, chromeflags); ... some code that causes widget realization... ... This is because the underlying nsWindow needs to be created with the correct window type, and it needs to know the chrome flags before realization for that to happen.
All I can say is, 1. THANK YOU for your interest in fixing this. I know Epiphany is about to drop gecko for webkit entirely, but even giving respite from this bug for a few weeks/months/whatever before the switch will be MUCH appreciated. As for build information... you can see how the Debian packages of epiphany invoke the build process at http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/epiphany-browser/debian/rules (look at the common_configure_flags and gecko_configure_flags lines). As for gecko, you can see the output of the build process including the commands used to configure it at <https://buildd.debian.org/fetch.cgi?pkg=xulrunner;ver=1.9.0.12-1;arch=i386;stamp=1248301455>.