Bug 1778803

Summary: web.whatsapp.com doesn't work (doesn't load the QR code) in GNOME Web
Product: [Fedora] Fedora Reporter: Vratislav Podzimek <v.podzimek+fedora>
Component: webkit2gtk3Assignee: -RETIRED- <erack>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: erack, gecko-bugs-nobody, gnome-sig, harbercandelario6kzj, jhorak, john.j5live, mcatanzaro+wrong-account-do-not-cc, mclasen, phatina, revo.ch, rhughes, rstrode, sandmann, tpopela
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-02 16:52:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vratislav Podzimek 2019-12-02 14:19:47 UTC
Description of problem:
When I open web.whatsapp.com in GNOME Web, it doesn't load the QR code to scan on my phone. So the "WhatsApp desktop application" I created using GNOME Web (my only use of GNOME Web, btw) no longer works. If I do "Log out", then the QR code sometimes loads, but quitting GNOME Web and running it again fails to load the WhatsApp UI.

Version-Release number of selected component (if applicable):
epiphany-3.32.5-1.fc30.x86_64

How reproducible:
100%

Steps to Reproduce:
1. open 'web.whatsapp.com' in GNOME Web
2. if it loads the QR code, scan it on the phone in the WhatsApp application
3. quit GNOME Web
4. open 'web.whatsapp.com' in GNOME Web again

Actual results:
Doesn't work.

Expected results:
WhatsApp UI loading and working fine.

Additional info:
This works just fine with the version of GNOME Web on Fedora 29.

Comment 1 Michael Catanzaro 2019-12-02 16:52:21 UTC
Hi, this is https://bugs.webkit.org/show_bug.cgi?id=203404.

Comment 2 Vratislav Podzimek 2019-12-03 08:49:03 UTC
(In reply to Michael Catanzaro from comment #1)
> Hi, this is https://bugs.webkit.org/show_bug.cgi?id=203404.

Thanks for the link. But I don't think closing this bug makes sense when the upstream bug is still open.

Comment 3 -RETIRED- 2019-12-03 15:27:48 UTC
That's the normal procedure saying "this is tracked in upstream bug ..." hence the status CLOSED UPSTREAM.
It does not make sense to track things twice.

Comment 4 Michael Catanzaro 2019-12-03 15:48:13 UTC
I mean, we can leave it open if you like, but it will just clutter the list of open bugs and the odds of anyone working on it here are roughly 0%. I prodded upstream, so there's some chance it will get noticed.

Comment 5 Vratislav Podzimek 2019-12-03 20:35:41 UTC
(In reply to Eike Rathke from comment #3)
> That's the normal procedure saying "this is tracked in upstream bug ..."
> hence the status CLOSED UPSTREAM.
> It does not make sense to track things twice.

I always thought CLOSED UPSTREAM was more like "resolved in upstream, closing the downstream bug". Leaving this open gives people like me or anybody else hitting the issue a chance to learn what's the status of the issue without having to go and read through the upstream ticket. In particular, people in Fedora will want to know if this is resolved in some new version of WebKit in Fedora or not. And/or be notified if there are updates to test etc. So generally I think bugs should only be closed when they are resolved (and rejecting bug is a possible resolution, of course).

Comment 6 Tomas Popela 2019-12-04 05:32:06 UTC
Ahoj Vráťo,

the workflow differs across the components and projects. Here for WebKitGTK and also for other desktop components we are closing the bugs once they are moved upstream because of the reasons that Michael explained. It's a workflow that we are using from several years and it fits our needs. If user wants to get notified about the change he should subscribe to an upstream bug.

Comment 7 Vratislav Podzimek 2019-12-04 09:50:22 UTC
(In reply to Tomas Popela from comment #6)
> Ahoj Vráťo,
Ahoj :)

> 
> the workflow differs across the components and projects. Here for WebKitGTK
> and also for other desktop components we are closing the bugs once they are
> moved upstream because of the reasons that Michael explained. It's a
> workflow that we are using from several years and it fits our needs. If user
> wants to get notified about the change he should subscribe to an upstream
> bug.

Fair enough, but creating an account somewhere only to be able to find out when a bug gets fixed is a bit annoying. Do you guys update the downstream bugs with 'Fixed in version' once it gets resolved upstream and makes it to the Fedora packages?

Comment 8 Michael Catanzaro 2019-12-04 14:02:51 UTC
We don't usually update the downstream bug unless it's a very serious or high-profile issue. But Eike will make sure Fedora users receive updates within roughly a week of a fixed upstream release.

Comment 9 Harber Candelario 2021-04-22 09:00:59 UTC
You can try with this Whatsapp version: https://otherwhatsapp.com/

Comment 10 SamYe 2021-10-08 16:21:40 UTC
you can find last update of whatsapp dahabi from this site https://www.whatsgoldplus.app/2021/01/whatsapp-gold-download.html