Description of problem: After the latest update to firefox-2.0.0.8 and epiphany built against it, epiphany just sits with the loading icon spinning forever when trying to open gmail, hotmail, and facebook. Firefox still works correctly. Version-Release number of selected component (if applicable): epiphany-2.18.3-3.fc7 How reproducible: Always on certain computers Steps to Reproduce: 1. Open Epiphany 2. Go to www.gmail.com in the address bar Actual results: Status bar says, 'Redirecting to "mail.google.com"' and progress bar just sits at ~70%. Expected results: Gmail login page would show. Additional info: We're running F7 on roughly 100 different computers in our school, all using the same image with configuration differences to deal with different hardware. These computers automatically update from a local repository, and all of them are having this problem. My laptop is also running Fedora 7, but it wasn't set up from the same image all the others were. Epiphany runs perfectly on my laptop with no problems at all.
Works fine for me: epiphany.x86_64 0:2.18.3-3.fc7 firefox.x86_64 0:2.0.0.8-1.fc7 firefox-devel.x86_64 0:2.0.0.8-1.fc7
Curious. Neither stransky nor I am able to reproduce. Possible that a restart of the applications would help (maybe the versions in memory are still pointing to the old libraries?)
I've actually got the systems set up to do their updates on shutdown (having a bunch of students complaining that "the Internet's broken" because firefox was updated while they were running it isn't my idea of fun), so it's definitely not the fact that old libraries are in memory. As I've said, it does work for me on my laptop (as well as on my wife's). Either I've got something screwed up in the school image or there's some odd corner case bug we're hitting. I've tried wiping .gnome2/epiphany and even gone as far as trying to do an strace comparison, but I'm not even sure what to look at. I'd send you the image we're using except we don't have the bandwidth. So if there's anything I can do to help track this down, I'm happy to do it.
I guess a good starting point would be to run rpm -V firefox epiphany nss nspr And see if anything unusual turns up. It could indicate the RPM install got messed up somehow. Also try: export NSPR_LOG_MODULES=nsHttp:5 export NSPR_LOG_FILE=ephy-http.log epiphany ... load the pages in question... and examine that file for any weirdness. Attach it if you can't make sense of it. Finally, attaching the strace output of epiphany could also prove useful.
Okay, I've tracked down the problem. All of our Internet goes through a CentOS 5 box, 10.10.1.1 (gateway.lesbg.loc). We also allow access to the internet using NAT to certain ip ranges including my laptop and my wife's. For all others, access to the internet must be through the squid proxy running on 10.10.1.1. So, here's the problem. On all the school systems, we have used gnome-network-preferences to set the HTTP proxy to gateway.lesbg.loc 3128, and we have the "Use proxy for all protocols" button checked. But, it seems that while Epiphany uses the proxy for all http:// requests, it ignores it for all https:// requests. When the clients then attempt to access the pages directly, their requests are silently dropped as per our proxy rules. Not sure whether I should change the bug status, so I'll leave it. Also, thanks for the NSPR_LOG stuff, it helped point me in the right direction.
What is the output of these commands on your school system: gconftool-2 -R /system/http_proxy rpm -q gnome-vfs2 However, this looks to me like a bug in gnome-vfs2 package, not in Epiphany itself. Reassigning there.
Also, does explicitly setting the https proxy (ie, not using "Use for all protocols") help?
In response to #6: $ gconftool-2 -R /system/http_proxy use_http_proxy = true use_authentication = false host = proxy.lesbg.loc authentication_user = ignore_hosts = [localhost,127.0.0.0/8] use_same_proxy = false authentication_password = port = 3128 Note that proxy.lesbg.loc points to gateway.lesbg.loc $ rpm -q gnome-vfs2 gnome-vfs2-2.18.1-4.fc7 In response to #7: Yes, it does fix the problem (though I'd prefer not to do it on all our computers unless this is a WONTFIX... I've already poked the necessary holes in our firewall to keep us going until this does get fixed).
(In reply to comment #8) > use_same_proxy = false This looks interesting, does gconftool-2 -t bool -s /system/http_proxy/use_same_proxy true help? If yes, and you are certain that you correct settings in gnome-network-preferences (available from System/Settings/Internet and Network/Proxy), then this would be a bug in control-center.
Sorry, that was my mistake. I attempted #7 before running gconftool-2 for #6 and forgot to put the settings back. Here is the output after going back to the original settings, and I've verified that it's still *not* going through the proxy for https. $ gconftool-2 -R /system/http_proxy use_http_proxy = true use_authentication = false host = proxy.lesbg.loc authentication_user = ignore_hosts = [localhost,127.0.0.0/8] use_same_proxy = true authentication_password = port = 3128
I'm not really convinced this is a gvfs bug (which has not changed since F7 final) or a control-center bug (since GConf is set properly). But then again, I'm not sure this is an epiphany bug (since no code changed in epiphany either)... Wonder if simply rpm rebuilding the epiphany f7 package would help?
gnome-vfs itself doesn't have any shared code for handling the proxy conf, it just ships the gconf schemas for the settings. The gnome-vfs http module does have some code to handle this, but I don't think epiphany uses gnome-vfs for the actual http connections. Maybe epiphany has some code to convert these gconf settings into settings for the mozilla http engine?
There is a new release of firefox out which fixes some regressions introduced in .8. I wonder if these RPMs help: http://koji.fedoraproject.org/koji/buildinfo?buildID=23358 http://koji.fedoraproject.org/koji/buildinfo?buildID=23455 Other builds you might need to satisfy deps: http://koji.fedoraproject.org/koji/buildinfo?buildID=23381 http://koji.fedoraproject.org/koji/buildinfo?buildID=23370
Okay, it's going to take a while for me to download these, so let me get back to you once I've done that and tested them.
Sorry for the long delay. I've tested epiphany-2.18.3-4.fc7 (based on firefox-2.0.0.9) and epiphany-2.20.1-3.fc8, and it's still bypassing the proxy.
Reporter, could you please check in about:config in epiphany what's the value of network.proxy.type? If it is 1, try to set it to 0. Does it help?
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Sorry about the delay, I must have lost the e-mail containing comment #16. When I set network.proxy.type to 0 (it comes up as 1), then nothing works (as it doesn't seem to be using the proxy server at all). In a related note, network.proxy.ssl and network.proxy.ssl_port are unset (again, even after I've checked the box on gnome-network-preferences saying to use the same proxy settings for everything). These systems have all been upgraded to F8, so it is still a problem with Fedora 8's epiphany.
Cool, thanks for letting us know.
At this point, we're going to only be taking security fixes and major stability fixes into this release of Fedora. However, we still want to ensure the bug is fixed in the next version. We'd appreciate if you could test Firefox 3, available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping as the default in Fedora rawhide and provide feedback as to whether it still exists so we can file a ticket upstream to try to fix it in Firefox 3 before it is released.
I don't mind trying this, but I thought the problem is in epiphany-specific code rather than Firefox. If I'm wrong, I'll happily give Firefox 3.0 a shot.
Sorry, this is really an epiphany bug. My mistake. Anyway, reporter, do you see it still with the latest epiphany in F8?
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. [This is a mass-closing request, if you think that this bug shouldn't be closed, please, reopen with additional information.]
Sorry, I somehow missed the email for #23. Yes, the bug is still there in F8 (and I've just tested and it's still in Rawhide as well).
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.