Programmable tab context menus

Can there be some type of programmable tab functionality where, we set context menus on tabs. Example:

Let’s take a tab with the YouTube origin and YouTube implements the context menu when clicked on they add whatever functionality they want, like playing video, pausing video. Muting not needed since chrome already does that.

How would this work I’m not really sure, context menus in HTML are not even fully supported right now.

Anywho maybe it’ll be the same just the type would be tab or something

<menu type="tab" id="tabMenus">
    <menuitem label="Play">
    <menuitem label="Pause">
</menu>

And the javascript would be something like:

tabMenus.addEventListener('click', function(e) {
    var video = document.querySelector('video'); //Im sure youtube stores video element another way
    (e.target.label == "Play") ? video.play() : video.pause();
});

So now if I’m browsing on one tab and YouTube video is playing on another, I don’t have to click on the tab and pause the video, now I can just right click and press pause. This is one example I’m sure more people can think of other examples.

Also chrome allows tab highlighting so what if I highlight multiple YouTube tabs and click pause then all of them pause. The context menus would only show up if the highlighted tabs share the same origin or path.

Please let me know if this has been discussed?

P.S I wasn’t sure what category this should be under but because it should be programmable I thought it’d be in API’s

Like most browser chrome features outside the frame, I wouldn’t want sites to have access to this.

That said, this is something I want to see exposed in the APIs offered for browser extensions (so it could be used by extensions like OneTab that manage tabs).

I don’t understand why you wouldn’t want sites to have access to this?

I was thinking, who knows maybe there’s a security threat that I don’t see, is there?

Please elaborate, I’m not sure what’s bad about this.

This seems like a reasonable idea to me. Native mobile apps support some quick actions (eg. to be used from the lock screen). Having some generic way to register quick actions (perhaps only a few pre-defined ones like ‘pause’) seems reasonable to me. Of course it would be up to the UA to decide if/how to surface the actions to the user.

@RickByers are you suggesting adding something for this to manifest.json? Or should it be an API, or a <meta>?

I’m still confused, what’s the security concern? If depending on the origin there’s different menus, not certain specific menus (a standard).

And @stuartpb I’d say an API, simply because I’m comparing it to caching, and Service Workers, API’s add more flexibility compare to a manifest.json and <meta> depends how the API’s written.

@stuartpb I haven’t thought about this enough to have a strong opinion on the API shape. Both manifest.json or some JS API seem likely to be reasonable to me. I suppose you may want dynamic actions, so maybe a JS API is better than something static. <meta> is a little hacky IMHO, but maybe good enough here?

This concept inherently invokes callbacks, so a JS API seems like the sensible choice in this case.

I had a whole rant here about needlessly non-declarative specs, but I’ll save that for another post.

It’s a phishing problem. Any time you let end devs imitate system features, it’s going to get abused. Think of pages that extend the message on the “Do you want to close this window?” popup to be several lines long in order to trick the user into ignoring its actual function to make it seem like the user was trying to do something else.

More directly, think of the flash drives that tricked users into installing malware on Windows by adding an item to their AutoPlay manifest that said “Open in Explorer”, which actually installed the malware and then opened the contents of the drive in Explorer.

That’s an interesting thought, so for standardized functionality what list of features do you have in mind? That lots of pages could use?

FYI, Chrome for Android just got a specific feature related to the larger idea here. It’s just play/pause media only (presumably using the same mechanism in Android I mentioned that gives quick actions on the lock screen), but perhaps a small step in the direction of a more general feature. This is quite a co-incidence - I wasn’t at all aware that this was being worked on .

That’s a very positive development, @RickByers. I also agree with the commenter who mentioned how great it’d be to be able to use the media keys on the keyboard for controlling web playback - the lack of that integration is the main reason I don’t much use web services for music, and I’m sure I’m not the only one.

In theory I can see the appeal for speccing a more generalised version of that to define some page-wide commands that may be exposed outside the page context, but I can’t come up with a use case off the top of my head that doesn’t fall under the umbrella of media controls. Does anyone else have a good use case like that?

I will say if something like this is specced, it’d be better to name it something abstract like <menu type="meta"> as it could be implemented in many different ways depending on UA - e.g. the Android lock screen/notification area controls in @RickByers’ link.

I agree that the priority here seems to be implementation issues with media playback. Eg. I like the idea where one tap is playing media, media keys in any tab (which don’t consume those key events) should trigger play/pause in the one tab (as if there’s one tab with “media key focus”). If you wanted to file a chromium bug for this I could help route it to the right engineers.

Doing something more general might be nice, but I don’t see a hugely compelling use case myself. Maybe custom playback controls like “next album” vs. “next track” etc?.

It’s a phishing problem because increasing the surface area of an origin is risky.

There appears to be lots of issues here:

• What prevents a site spamming the users menu
• What prevents a site exposing another pages menu items
• Would this be something that would just be exposed to installed apps via a manifest
• Could sites choose their own item names?
• Would this feature just be generalised tasks (Kind of like web-intents but that might cause events on a service worker perhaps)

As @RickByers mentioned Android Chrome now has the global pause; this is similar however the user has started playing media which the browser has decided to give the user the option to control through new mechanisms. Registering specific behaviour on the other hand seems far more problematic because of some of the issues raised above which would need to be answered.

I can see only two avenues for something like this:

• Exposing a standardised control to the user similar to the Android behaviour based upon existing web behaviour. (This would mostly be user-agent specific in appearance and behaviour)
• Adding menu items when the site has:
  • a service worker
  • secure context (https://w3c.github.io/webappsec/specs/powerfulfeatures/)
  • a manifest and user has installed

Apologies for reviving this but, what if it just showed a site’s bookmarks and there was an API to silently bookmark the current page? Importantly, it should look and act like bookmarks and show the site icon and title and everything.

On mobile it’d show a “bar” similar to a bookmarks bar, with a button you click to view site bookmarks. But this would be implemented in the browser and available to all websites, seamlessly.

Never. A user must have control over such things. Why expose an API for a site to just do whatever they want regardless of what the user wants?

What exactly are you attempting to achieve through this API desire? What use-case where this improves a users work-flow?

Providing the ability to integrate website “save” feature with the browser, mostly. For example, reddit has “save” buttons, and on here we have “bookmark” buttons. These could be made to integrate with the browser.

Note that said bookmarks would be managed separately from user bookmarks. User bookmarks would continue working as they currently do but these would be an extra UX improvement for the user. They’d also be consistent across websites (instead of hidden behind various menus - reddit hides it behind 1 click, on here they’re hidden behind 2 clicks, and neither are searchable etc).

So you want to overload bookmarks (or some new similar feature) to per-origin bookmarks that are either hidden to the user in the UX or exposed through a new interface.

Honestly, I don’t agree with UA’s needing to do this. Bookmarks are the browser-level page specific method of saving something. Anything sites want to do in this area is best handled in them. Not many sites have page-specific saving like that, it’s pretty abnormal based on a specific situation of a site.

This also has potential pitfalls in that context of exposing a surface area that greatly increases an origin’s ability to track a specific user if this feature is used to store data and retrieve the entire list. As then even an anonymous user who may have saved a page (which certainly can’t be silent but instead by a user gesture, which then can be mangled so it would need to also be UA controlled for that) can have an origin query up the list and provide it along with other related metadata to a 3rd party to target them more.

I think your feature request would probably need it’s own thread rather than attaching it here. IF the privacy and UX issues could be worked out then perhaps it has a chance of going somewhere. But I’d also be very interested in real user data of who is asking for sites to have this ability.

Websites wouldn’t be able to manage arbitrary bookmarks, only the ones they create. There’s no danger other than the same dangers as local storage – actually, if anything, there’s less danger, as all the data is visible to the user, either through the tab context menu or through something equivalent.

However, integrating bookmarks with websites would encourage users to make use of them. And also it just looks cool. Just, having the bookmarks in the tab context menu? Cool af. We should do more of that.

Yea, good point with the potential space of tracking. It’s just on-level with what is currently available. Still, your request should be in its own thread for more discussion I believe. Rather than overloading a quasi-related one.