Websites keep asking for notification authorization even if policy is set to "true"

[bascht]

This might be a possible regression of #832 but I am not sure if this is expected behaviour.

Version info (see :version):

qutebrowser v1.8.1
Backend: QtWebEngine (Chromium 73.0.3683.105)

CPython: 3.7.6
Qt: 5.13.2
PyQt: 5.13.2

sip: 4.19.19
colorama: 0.4.1
pypeg2: 2.15
jinja2: 2.10.1
pygments: 2.4.2
yaml: 5.1.2
cssutils: 1.0.2 $Id$
attr: 19.1.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: yes
PyQt5.QtWebKitWidgets: yes
pdf.js: no
sqlite: 3.30.0
QtNetwork SSL: OpenSSL 1.1.1d FIPS  10 Sep 2019

Style: Adwaita::Style
Platform: Linux-5.4.18-200.fc31.x86_64-x86_64-with-fedora-31-Thirty_One, 64bit
Linux distribution: Fedora 31 (Workstation Edition) (fedora)
Frozen: False
Imported from /usr/lib/python3.7/site-packages/qutebrowser
Using Python from /usr/bin/python3
Qt library executable path: /usr/lib64/qt5/libexec, data path: /usr/share/qt5

Paths:
cache: /tmp/qutebrowser-test/cache
config: /tmp/qutebrowser-test/config
data: /tmp/qutebrowser-test/data
runtime: /tmp/qutebrowser-test/runtime

Autoconfig loaded: yes
Config.py: no config.py was loaded
Uptime: 0:00:22

Does the bug happen if you start with --temp-basedir?: The issue is hard to reproduce with a temporary basedir (I need to save the settings to reproduce it), but it does happen with a --basedir set to a fresh /empty folder.

Description

I am using this site to reproduce the issue. It seems that even with the following autoconfig.yml (and no config.py) in a fresh basedir:

config_version: 2
settings:
  content.notifications:
    global: ask
    https://www.bennish.net: true

Once I have set the policy to true and allowed the website to display notifications by confirming the dialog

with Y I would expect that I can open up https://www.bennish.net/web-notifications.html and have it display notifications right away.

Qutebrowser will remember the authorisation and won't display this dialog again – yet the website still does have to request permissions from the browser before it is allowed to send notifications. This behaviour differs from other Browers.

If I confirm Chromium or Firefox's dialog to allow notification on https://www.bennish.net/web-notifications.html the website can display Notifications right away by hitting the Show button, even after restarting the browser. I no longer need to click the "Authorize" button.

How to reproduce

• Use above /tmp/qutebrowser-test/config/autoconfig.yml
• Open qutebrowser --basedir=/tmp/qutebrowser-test https://www.bennish.net/web-notifications.html
• Click Show
• No notification shown (site displays Notification #1 queued for display / Notification #1 errored)
• Click Authorize
• Click Show
• Notification is shown

The issue is also not specific to that test website. Slack shows the same behaviour – asking for permissions even though I granted and saved it:

[The-Compiler]

As far as I'm aware, this is a limitation in Qt's API. I'll take care of opening a Qt issue about it.

[bascht]

@The-Compiler you're right. Just tried Falkon (3.1.0 w/ QtWebEngine version 5.13.2) and it shows the same behaviour.

[The-Compiler]

Reported upstream: [QTBUG-83476] Add a way to remember permission authorizations - Qt Bug Tracker

[The-Compiler]

There was a surprisingly quick upstream change: Document early feature reply (Ie4562e93) · Gerrit Code Review

I'm a bit confused by the commit message - it could mean that calling setFeaturePermission early already works on earlier Qt versions. Should try and see what happens.

[bascht]

I meanwhile redneck-engineered my way around this, so if anyone else stumbles upon this issue: At least for slack I could fix it with a greasemonkey-script:

// ==UserScript==
// @name        Fix Slack Notifications
// @description Hits the notification button, once
// @version     1.0
// @namespace   https://app.slack.com/
// @match       https://*.slack.com/*
// @match       https://*.slack-edge.com/*
// @run-at document-idle
// @grant       none
// ==/UserScript==
(function() {
    'use strict';

    var waitForThatFrickingButton = setInterval(function() {
        let xpath = "//button[text()='enable desktop notifications']";
        let button = document.evaluate(xpath, document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue;
        if(button) {
            button.click();
            clearInterval(waitForThatFrickingButton);
        }
    }, 500)
})();

(As it's a SPA I have to wait for the button to actually appear :see_no_evil:)

[The-Compiler]

Another related change in Qt, probably will land in 5.15.1: Allow to set feature permission before first ever navigation (I63a3cbca) · Gerrit Code Review

and more:

• Add support for clearing the feature request (I63ad9801) · Gerrit Code Review
• WIP: Answer automatically on request for known features permissions (I3a9b09a3) · Gerrit Code Review

[C0DK]

The QT bug you reported (https://bugreports.qt.io/browse/QTBUG-83476) seems to argue that it should be handled on an application level. Would this be possible? i am a bit annoyed at constantly dismissing the popup on reddit :D

[The-Compiler]

@C0DK have you tried answering "never" to that popup?

[knezi]

i am a bit annoyed at constantly dismissing the popup on reddit :D

Me too :D. You can use: (for all domains)

c.content.notifications = False

Or for a particular domain:

config.set('content.notifications', True, '*://reddit.com')

[C0DK]

@C0DK have you tried answering "never" to that popup? Yes however much like this very issue, it doesn't seem like it is actually remembered in the browser.

I will try @knezi's solution, thank you.

[The-Compiler]

Yes however much like this very issue, it doesn't seem like it is actually remembered in the browser.

No, this issue is about something different: It's not about qutebrowser's dialogs, it's about websites which have some kind of "you should let us enable notifications" bar before they actually ask qutebrowser for a notification permission. In other words, it's about letting websites know they're allowed to send notifications before they actually ask for it.

If you get qutebrowser's prompts despite answering 'always', I'm guessing you have a config.py but don't load autoconfig.yml from it.

[markstos]

I'll also add th keywords "Zoom" and "Google Meet" to this issue, as those are commonly used sites that ask for webcam and microphone permissions.

[The-Compiler]

FWIW over in https://github.com/qutebrowser/qutebrowser/issues/5433#issuecomment-869864679, @kguidonimartins added the workaround script to work for WhatsApp Web.

It could be improved by using a MutationObserver instead of polling, if someone feels inclined to do so. But ideally we'd have a proper fix for this anyways, of course.