Bug 1778803 - web.whatsapp.com doesn't work (doesn't load the QR code) in GNOME Web
Summary: web.whatsapp.com doesn't work (doesn't load the QR code) in GNOME Web
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: webkit2gtk3
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: -RETIRED-
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-02 14:19 UTC by Vratislav Podzimek
Modified: 2021-10-08 16:21 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-12-02 16:52:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
WebKit Project 203404 0 None None None 2019-12-02 16:52:20 UTC

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


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