Epiphany (gnome-web) - webkit - intermittently breaks

Hey There

I love the obscure problems. I can’t seem to web search myself out of this one. I’m not even sure if this is Fedora specific, but it’s happening on Fedora 35. I’m hoping someone smarter than me cares enough about Epiphany and Fedora to help me out.

I’m trying to use a webkit browser to do debug testing for what would most likely be Safari related problems. I have a KVM with MacOS setup, but to hell if I want to start MacOS every time something that might be a webkit issue crops up.

The minute I opened Epiphany or Midori, I get multiple timeouts and failed DNS resolutions. Sometimes I can resolve this with a reboot/resetting my network/systemd-resolved, but it always comes back and it’s super annoying. It gets so bad that I can’t even load duckduckgo.com.

This doesn’t happen in FireFox or Blink based browsers. I’m not even sure where to start with useful debug info, I apologize.

Does anyone have any ideas?


Seems you found a webkit bug, as Safari and Epiphany on your machines do have problems. Did you look in https://bugs.webkit.org/?
Was a backtrace on Epiphany crash possible? (StackTraces - Fedora Project Wiki) File a bug on this problem on buzilla Red Hat Bugzilla Main Page. and /or https://bugs.webkit.org/.


Appreciate it. I’ll give that a shot.

There’s no crashing, which makes it harder to describe what’s wrong for sure.

1 Like

Let’s try to isolate the issue by enabling DoT:

sudo tee /etc/NetworkManager/conf.d/00-custom.conf << EOF > /dev/null
sudo systemctl restart NetworkManager.service
sudo rm -f -R /run/systemd/resolve/netif
sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/00-custom.conf << EOF > /dev/null
DNS= \
2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
sudo systemctl restart systemd-resolved.service
1 Like

Ahhh I wondered if I’d get to hear from you again!

I’ve set up these custom rules - (thanks for the tip on bypassing NetworkManager for DNS as whole!) - and the problem persists.


1 Like

Some parameters might have changed, so it would be best to see an update of your configuration:

resolvectl flush-caches; \
resolvectl --no-pager status; \
resolvectl --no-pager query discussion.fedoraproject.org; \
env | grep -i -e proxy; \
grep -v -e "^#" -e "^$" /etc/nsswitch.conf

Also when you see the error “Unable to display this website”, expand the “Technical information”.

1 Like


         Protocols: LLMNR=resolve -mDNS +DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server:
       DNS Servers:

Link 2 (wlp2s0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Link 3 (virbr0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
discussion.fedoraproject.org: 2602:fd3f:3:ff01::cc    -- link: wlp2s0
                        -- link: wlp2s0

-- Information acquired via protocol DNS in 20.1ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: network
passwd:     files sss systemd
group:      files sss systemd
netgroup:   sss files
automount:  sss files
services:   sss files
shadow:     files
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
aliases:    files
ethers:     files
gshadow:    files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files

As requested, in the technical information we see:


Sure looks like systemd-resolved is working fine. That’s good.

In your bug report you proved that something is going very wrong with DNS. I’ve attached a test script there to see if GResolver is working properly. As long as systemd-resolved is happy, GResolver should be too… but this is weird, so maybe not.


One more thing to test:

$ cat /etc/nsswitch.conf | grep hosts:

1 Like


#     hosts: files dns
#     hosts: files dns  # from user file
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

1 Like

FYI to anyone who may be interested in this, the bug reporting has moved upstream to WebKit


We were able to narrow down the bug to GSocketClient and have moved back to to Red Hat for debugging:


We further narrowed down the issue to the setting org.gnome.system.proxy mode being erroneously toggled to “auto”. This was probably a mistake I made at some point that reared its ugly head only while using Epiphany. No proxy was configured and the discovery process tied things up.

Set that to “none” (or “Off” in the GUI) and Epiphany works as intended.

Big thanks to @catanzaro for sticking with me through this process


Yep, this is not a DNS related error, otherwise it would look like this:

Next time, you can isolate this kind of issue by testing from a new user with default profile.

Anyway, thanks for your support. :smiley: :+1:

1 Like