New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

Issue 656696: Provide always-on-top functionality to extensions from or create

Reported by, Oct 17 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce the problem:
Due to the recent change to chrome removing support for Chrome Panels (see some extensions will stop functioning as there is no suitable replacement in some scenarios.

In particular, it will no longer be possible to display arbitrary content that is "always on top". I have filled this issue on behalf of users in the issue linked above. In that issue, there are many scenarios mentioned and they all boil down to missing "always on top" functionality.

Chrome does offer a replacement for some scenarios. In particular, my extension (Plus for Trello) is currently migrating to use chrome notifications. Thankfully since Chrome 50 notifications now support "requireInteraction" which allows to leave the notification up indefinitely (until the user clicks) thus I can simulate my always-on-top "timer" window by having a notification that gets its content updated every second so the timer "ticks". Not great because now the window will cover twice as much of the screen area, and notifications cannot be minimized or even moved to see what is covering behind.

Also, using notifications is very limiting because all you can do is update a few properties of the notification but cannot display arbitrary content (like the PIP youtube extension mentioned in the other issue).

I realize that providing always-on-top opens the door again to abusing popups. However, if the API limits this new flag just to extensions and given that extensions are centralized in the webstore, it seems this will mitigate the problem that the other issue will generate with the hundreds of thousands of combined users, many of them developers themselves.

I have tried using the and .update to set alwaysOnTop from an extension background page and have verified that this is a read-only property.

What is the expected behavior?
alwaysOnTop to be a property modifiable from an extension

What went wrong?
alwaysOnTop is a read-only property.

WebStore page:

Did this work before? No 

Chrome version: 53.0.2785.143  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

This worked before for users that had enabled chrome panels. Yes, it was an experimental feature but it was available for many years and even a Google extension (Hangouts, which millions of users) heavily used them setting an example to follow.

Comment 1 by, Oct 18 2016

Components: -Platform>Extensions Platform>Extensions>API UI>Browser>Panels
Adding respective Components for more inputs on this.

Comment 2 by, Oct 18 2016

Hm... This is not about panels. It was a panel functionality, but this is a general request for always-on-top support.

Comment 3 by, Oct 19 2016

FYI, while trying to workarround this issue (by using chrome notifications) I stumbled on this other new issue:

Which causes notifications to get lost even when using the "requireInteraction" flag.

Comment 4 by, Oct 20 2016

Here is an animation showing how I managed to implement minimizable chrome notifications.
61.9 KB View Download

Comment 5 by, Jun 20 2017

Status: WontFix (was: Unconfirmed)
Panels were removed from Chrome, except ChromeOS. See bug 571511.

Sign in to add a comment