Programmable tab context menus


#1

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


#2

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).


#3

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.


#4

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.


#5

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


#6

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.


#7

@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?


#8

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.


#9

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.


Can we get a "Security" category?
#10

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


#11

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 :smile:.


#12

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.


#13

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?.


#14

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: