New issue
Advanced search Search tips

Issue 900198 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 696617



Sign in to add a comment

A click on a shared worker thread shouldn't trigger user activation on any frame/renderer

Project Member Reported by mustaq@chromium.org, Oct 30

Issue description

We noticed this test while working on a test failure:
third_party/WebKit/LayoutTests/http/tests/notifications/click-shared-worker.html

This test assumes that click on a notification would activate a renderer (in other words, the renderer will be considered to have received a user gesture).

With User Activation v2, there would be no renderer-wide activation.  The question is: which frame to activate?

There is a bigger question here that is independent of UAv2: how would the user associate a click on a notification to a particular tab?  Since users don't "see" a background shared worker, any notification invoked by the worker could be perceived to belong to any/none of the tabs.  This could lead to potential abuse of user activation.

 
Project Member

Comment 1 by bugdroid1@chromium.org, Nov 1

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fcf2e2301ba0e4b9cdd6df3946b044c9f7c882dd

commit fcf2e2301ba0e4b9cdd6df3946b044c9f7c882dd
Author: Mustaq Ahmed <mustaq@google.com>
Date: Thu Nov 01 17:23:48 2018

Skip user activation notification when doc or frame is not available.

Change-Id: I4b30c9adb106e85e2e713af0d931f900123885be
Bug: 900198
Reviewed-on: https://chromium-review.googlesource.com/c/1307845
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604626}
[modify] https://crrev.com/fcf2e2301ba0e4b9cdd6df3946b044c9f7c882dd/third_party/blink/renderer/modules/notifications/notification.cc

Blockedon: 696617
Owner: mustaq@chromium.org
Status: Assigned (was: Available)
Not sure how many activation notification calls we need to fix.  May be we are done.  If not, the following tests may need to be checked---they seem to access the activation state from a worker thread (as we found in crrev.com/c/1299537/4).

PushMessagingBrowserTest.ResubscribeWithMismatchedKey
PushMessagingBrowserTest.ResubscribeWithoutKeyAfterSubscribingFromDocumentWithNumber
PushMessagingBrowserTest.ResubscribeWithoutKeyAfterSubscribingFromDocumentWithP256Key
PushMessagingBrowserTest.ResubscribeWithoutKeyAfterSubscribingFromWorkerWithNumber
PushMessagingBrowserTest.ResubscribeWithoutKeyAfterSubscribingFromWorkerWithP256Key
PushMessagingBrowserTest.ResubscribeWithoutKeyAfterSubscribingWithKeyInManifest
PushMessagingBrowserTest.SubscribeWorker
ServiceWorkerTestWithJSBindings/ServiceWorkerTest.TabsCreate/0
ServiceWorkerTestWithJSBindings/ServiceWorkerTest.WorkerRefCount/0
ServiceWorkerTestWithNativeBindings/ServiceWorkerTest.TabsCreate/0
ServiceWorkerTestWithNativeBindings/ServiceWorkerTest.WorkerRefCount/0

Maybe user activation v2 should actually be tied to ExecutionContext? Conceptually clicking a notification is kind of like granting user activation to the worker, no?

(I don't think I quite follow the reason why a click on a notification has to be associated with a particular tab)
I agree that a notification click can activate the associated worker.  But it's not clear to me if a Worker can benefit from it at all, given that it has no access to DOM (hence can't call window.open(), element.requestFullscreen() etc).

Sign in to add a comment