Bug 358121 - Loading stops for gmail, facebook, etc.
Loading stops for gmail, facebook, etc.
Product: Fedora
Classification: Fedora
Component: epiphany (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-10-30 09:02 EDT by Jonathan Dieter
Modified: 2009-07-14 12:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 12:57:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Dieter 2007-10-30 09:02:16 EDT
Description of problem:
After the latest update to firefox- 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):

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.
Comment 1 Martin Stransky 2007-10-30 09:22:50 EDT
Works fine for me:

epiphany.x86_64 0:2.18.3-3.fc7
firefox.x86_64 0: 
firefox-devel.x86_64 0:
Comment 2 Christopher Aillon 2007-10-30 09:25:51 EDT
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?)
Comment 3 Jonathan Dieter 2007-11-01 14:29:11 EDT
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.
Comment 4 Christopher Aillon 2007-11-02 06:00:01 EDT
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
   ... 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.
Comment 5 Jonathan Dieter 2007-11-02 07:42:13 EDT
Okay, I've tracked down the problem.  All of our Internet goes through a CentOS
5 box, (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

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.

Comment 6 Matěj Cepl 2007-11-02 08:36:03 EDT
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.
Comment 7 Christopher Aillon 2007-11-02 08:43:37 EDT
Also, does explicitly setting the https proxy (ie, not using "Use for all
protocols") help?
Comment 8 Jonathan Dieter 2007-11-02 09:35:02 EDT
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,]
 use_same_proxy = false
 authentication_password = 
 port = 3128

Note that proxy.lesbg.loc points to gateway.lesbg.loc

$ rpm -q gnome-vfs2

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).
Comment 9 Matěj Cepl 2007-11-02 10:10:42 EDT
(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


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.
Comment 10 Jonathan Dieter 2007-11-02 10:56:31 EDT
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,]
 use_same_proxy = true
 authentication_password = 
 port = 3128
Comment 11 Christopher Aillon 2007-11-06 09:01:36 EST
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?
Comment 12 Alexander Larsson 2007-11-06 11:00:55 EST
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?
Comment 13 Christopher Aillon 2007-11-07 07:19:47 EST
There is a new release of firefox out which fixes some regressions introduced in
.8.  I wonder if these RPMs help:


Other builds you might need to satisfy deps:
Comment 14 Jonathan Dieter 2007-11-08 00:17:24 EST
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.
Comment 15 Jonathan Dieter 2007-11-14 09:24:45 EST
Sorry for the long delay.  I've tested epiphany-2.18.3-4.fc7 (based on
firefox- and epiphany-2.20.1-3.fc8, and it's still bypassing the proxy.
Comment 16 Matěj Cepl 2007-11-15 09:48:37 EST
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?
Comment 17 Matěj Cepl 2008-01-18 07:24:20 EST
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.
Comment 18 Jonathan Dieter 2008-01-18 08:31:57 EST
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.
Comment 19 Matěj Cepl 2008-01-18 11:53:46 EST
Cool, thanks for letting us know.
Comment 20 Matěj Cepl 2008-02-21 17:36:12 EST
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.
Comment 21 Matěj Cepl 2008-02-21 17:37:08 EST
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.
Comment 22 Jonathan Dieter 2008-02-22 00:43:04 EST
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.
Comment 23 Matěj Cepl 2008-02-22 04:39:31 EST
Sorry, this is really an epiphany bug. My mistake. Anyway, reporter, do you see
it still with the latest epiphany in F8?
Comment 24 Matěj Cepl 2008-04-09 10:05:47 EDT
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


[This is a mass-closing request, if you think that this bug shouldn't be closed,
please, reopen with additional information.]
Comment 25 Jonathan Dieter 2008-04-09 10:35:10 EDT
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).
Comment 26 Bug Zapper 2008-05-13 23:47:38 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 27 Bug Zapper 2009-06-09 19:08:16 EDT
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: 
Comment 28 Bug Zapper 2009-07-14 12:57:10 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.