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 57 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 597657: Evaluate page action UX in new toolbar design

Reported by, Mar 24 2016 Project Member

Issue description

There have been several different thoughts on what to do with page actions with
the extension toolbar redesign, including popping them out of overflow, coloring
or badging them, etc (  has some of the various attempts). In the
end, most of these felt very awkward, and the consensus UX reached was that
page actions primarily fall into two categories:
- Those that act on most pages (and can live in the toolbar) - e.g. Stars
- Those that act on specific, user-intuitive circumstances (and can live in the
  overflow menu and the user will know when to activate it) - e.g. Turn Off the
And for these categories, a very light-weight treatment for page actions is

There is a class of page actions that doesn't fall into this category, and for
whom some different UI treatment would be advantageous.  In order to better
facilitate the design, the team has requested specific examples of page action
extensions and use cases that are degraded significantly by the new toolbar.
A few from forums that I've seen include:
- Google RSS Subscription: is active iff there is an RSS feed available to
  susbscribe to on the page (
- The Camelizer: is active if it can display pricing data for a product on the
  page. (

Please add other specific examples and use cases to this bug so that the UX team
can best evaluate the problem and determine if a better solution is possible.

Comment 1 by, Mar 28 2016

The new page action treatment relies on graying out icons that can't be used which poses problems for
a) Accessibility, since it hinders usability for anyone with colorblindness.
b) Extensions with gray-ish icons to begin with (e.g.

Comment 2 by, Mar 28 2016


Comment 3 by, Apr 1 2016

last-fm scrobbler would be an example from me ( The information is mostly provided by the icon that displays the scrobbling status, would be ideal to have it visible (but not permanently as with those that act on most pages)

May I ask why it's felt that it needs to be altered how page actions work at all compared to the old system? Having a single consistent, simple place they end up that shows only relevant icons seemed (and seems) the best solution in my opinion--rather than these multiple scenarios.

The omnibar served that purpose very well, I've read a few of the suggestions and would agree that many do sound a bit awkward and haven't convinced me personally. But that may just be because the omnibar was already such a logical choice: 

- It's right next to the extensions area already
- The omnibar is known by users to be per page as the URL changes, the extensions area itself is a more global thing
- Removes the requirement to dig into a menu for your user-intuitive scenario (hidden actions tend to be used far less)
- It's far more visible, it's much easier to spot a new icon than whether or not an existing one has been altered slightly at a glance

Comment 4 by, Apr 1 2016

Use cases
* PDF Viewer (pdf.js): active when viewing pdf, click to see proper URL of file, since the extension interface currently requires showing as an extension URL (
* Flix Plus / Magic Actions: appears on Netflix / Youtube pages respectively to indicate that they are modifying the page. click to open dashboard which includes settings and other options ( /

Additional comments. The new UX is impossible to manage on Mac/OSX because we CANNOT rearrange extensions on the hamburger menu. And the new interaction UX with extensions in the hamburger menu is an absolute hacky mess. They slide out of the hamburger menu briefly, sometimes the hamburger menu does not close, and everything gets shuffled around or hidden or not hidden during interaction. It's a complete mess.

Comment 6 by, Apr 1 2016

Question: Why are built-in extensions like Translate still allowed this option, but not third-party options? Shouldn't users know about the Translate extension? Why aren't such extensions shown in the extensions manager or in the hamburger menu?

Comment 7 by, Apr 1 2016

@abwicks Translate is a component of chrome that happens to be implemented (in part) as an extension, but the fact that it is an extension is just an implementation detail.  Other component extensions (bookmark manager, google now, pdf view, etc) are treated the same way - they're a part of chrome.

Comment 8 by, Apr 1 2016

Bring back good old page actions. There was no need for removing them from address bar at all.

Comment 9 by, Apr 1 2016

Let me get this straight, you colossally (by not doing UX testing) botch a fix to an obscure issue and then you decided you need a fix for that 'fix'?

Merging and dodging issues won't help you.

Here's the problem at hand:

And here's a simple fix:

Why is it that chrome://extensions is not enough? Because some people cannot find it/don't know about it and I can't blame them. Why not pull the extensions out of the Tools submenu to increase discoverability? Possible onto main menu or even on the bookmarks bar next to Apps to *really* rub it in. There, problem solved.

Now, bring the old page action behavior back. It had a purpose. There had been structure and logic behind the concept. I would link to the docs but it seems you've rewritten them. Fortunately for us, the Internet remembers:

Comment 10 Deleted

Comment 11 by, Apr 1 2016

I like that the number of extensions you have installed is no longer "hidden". I think this was the primary driver purpose of the UX revamp, and I honestly agree with it from a security perspective.

The main complaint I have is that the "Hide in Chrome Menu" does not work properly, see: It would be better if this "Hide in Chrome Menu" properly sync'd across devices, and did not exhibit this strange behavior.

Also, I think it might make sense to show some kind of notification that a Page Action is available without having to first click on the Chrome Menu.

Comment 12 by, Apr 1 2016

This bug is very specifically about examples of extensions which meet the criteria in comment 0.  This is not an appropriate place to debate the extension handling redesign in general or comment on other bugs.  It's especially not an appropriate place to effectively say that the UX team is either stupid or malicious, which only serves to make it less likely anything on this bug is paid attention to.

Please stay on topic, or I will begin deleting comments which do not do so, and if necessary lock the bug entirely.  General feedback is welcome, but please provide it in the Chromium help forums or in the chromium-discuss group, not here.

Comment 13 by, Apr 1 2016

An interesting example is the HTTP/2 indicator:

On one hand, it's active on almost every page and therefore is okay as a permanent toolbar button. This, however, loses the option to hide it for plain HTTP pages and forces to add a new state for pages it does not apply to (non-injectable pages like the Webstore or WebUI).

On the other: firstly, it's more of a visual indicator. Even though it has a click handler, it's main purpose is visual and it doesn't need as much screen space as a full toolbar button. This is a common problem with page action redesign: many of those extensions are there to provide an inobtrusive visual indicator accessible at a glance.

Secondly, its position in the address bar reinforced the mental connection between the information and the URL. In Chrome user's perspective the toolbar buttons are more independent/autonomous from the current page than old page actions.

Also, side note, the extension suffered from a bug until it was adapted for being on the toolbar: This may become an issue for unmaintained but popular page action extensions.

Comment 14 by, Apr 1 2016

Sorry, I misunderstood the purpose of this thread. My comment evaluating the effectiveness of the change was deleted. I in no way meant to be uncivil by suggesting that the level of impact must be considered and weighed against what, if any, benefit this UX change would make.

To stay much more on topic this time around, This is my suggestion. Actionable extensions (the ones people actually have to click on to do something e.g. Turn out the Lights) should be made visible because people actually need to act on them to make them work, where as, passive extensions that just do their job, should be put in the overflow as the user is not likely to click on them to perform an action. I believe this behavior should be the preferred method.

Comment 15 by, Apr 3 2016

My extension is an example.

I made the extension a couple of months ago (way before the UX change) and it it is currently being evaluated. Because of the change in UX they are not sure if they want the extension.

This extensions shows if a given webshop is certified by the Danish E-Mærket (E-Mark) and thus known to be a genuine webshop. If the shop is certified, the page action will show the icon and you can click it to see the certificate.

If the shop is known to be fraudulent, the icon will show a red warning triangle instead.

But since most websites are not webshops and not known by E-Mærket, there should by no visible icon for all these sites.

Comment 16 by, Apr 4 2016

Any pageAction that only needs to be rarely visible/visible on specific sites, is affected by this. 
My guess as an end user/dev is that extensions redesign was driven by: 
A. security reasons (raise awareness of what is installed) 
B. UX reasons ('singlify' the UI locations a user can interact with extensions). 

Problems with A: It forces you to always show all pageActions in the toolbar. If you just put them inside 'app menu' you aren't aware if the pageAction is enabled, which forces you to have them always aside 'app menu' which leads to horrible UI clutter. If you  just use the old design of showing pageActions inside address bar but also always display an extension button inside the 'app menu' my guess is that this would be a good compromise  for most of the users.

As far as point B, I think the design team overstretched the idea of reducing the UI surfaces a user can interact with an extension. It is an overstretch because by definition pageActions are only useful in some rare occasions/urls which contradicts with the need of an always showing extension icon. 

Furthermore the address bar is still being used as a surface a user can interact with internal extensions/components! Chrome password manager for example shows up inside address bar, and even more interestingly bookmarks star, which is more of a browserAction than a pageAction, also shows into the address bar!

At last don't forget that you can just do so much protecting your product client side. I've found in my sister's laptop malware which was bypassing the  default chrome installation with another install of chrome set up to use Privoxy as a proxy injecting scripts to pages, someone else can even patch the chrome executable directly etc etc. You end up messing with a big part of your user base for marginal security benefits.

Comment 17 by, Apr 4 2016

- Turn Off the Lights: is active if video is detected on page, allowing it to "dim" all other content on the page but the playing video.. (
- Alert Control: Controls browser alert windows. Block by default or on specific websites. Stop the browser alert dialogs from taking over the tab (
 - Bookmark Manager (by Google): Bookmarking made easier with the smarts of Google Search and a new modern UI. Add images and notes to your bookmarks to make them more helpful. (

As others have stated:
- The Camelizer
- PDF Viewer (pdf.js)
- RSS Subscription Extension

Additional Comments:
As previously stated (, it would be nice if the "Hide in Chrome Menu" synced across devices.

Comment 18 Deleted

Comment 19 by, Apr 11 2016

I like the new redesign, but would like to weigh in that a large number of my extensions are only applicable on a small number of pages, and I don't want them permanently taking up space in my toolbar.

The ideal solution would be: Iff I chose to hide an extension with a page action in the Chrome Menu, I still want the page action to come up in the address bar when active, as it used to before this redesign.

The whole greyed out/colored in switch can still be used if the button isn't in the overflow menu, but the page action should *always* be visible regardless if the extension was hidden or not. That's the reason the extension was installed in the first place!

Comment 20 by, Apr 11 2016

(@19, FWIW I have proposed precisely that solution repeatedly and had it shot down, so I'm not hopeful, even though to me as well that is the obvious way of handling this.)

Comment 21 by, Apr 12 2016

I personally do not want greyed-out rss icon visible on sites that do not have RSS.  The icon does nothing for me in that context which makes me want to hide it.  If I hide it, then I do not see if a page does have RSS; I would like it to be visible in that case.  Same goes for all of the other pageAction extensions that I use.

Comment 22 by, May 13 2016

Some more use cases:

- A button to show lyrics on specific (supported) music sites:

- A button to get a YouTube video to take the whole page (full screen within the window) (for personal use - not published).

- A button that only appears in the Chrome Web store, to view the source of the extension or download it:

And as someone else brought up before, in comment 4, a button to display the actual URL that is being displayed by the PDF.js PDF Viewer. But this specific use case would be resolved by having the ability to modify URLs of extension pages (

Comment 23 by, May 13 2016

 Issue 610339  has been merged into this issue.

Comment 24 by, May 13 2016

Use case (from the merged-in issue):

* is in the middle of a UI overhaul. The Gerrit UI Switcher switcher provides an easy way to flip back and forth between the old and new UIs. It is only applicable on * (button shouldn't be displayed on other domains), but if you bothered to install it, then it should always be displayed for those domains.

The new system is all or nothing. It has no concession for extensions which are meaningful on some pages but not on others. The API still has that: extensions can be BrowserActions or PageActions. But the UI not reflecting that true dichotomy is a poor user experience.

Comment 25 by, May 15 2016

 Issue 604724  has been merged into this issue.

Comment 26 by, May 16 2016

(+rpop@ for Desktop)

Comment 27 by, May 17 2016

There's also the good old Universal Edit Button:

HTTPS Everywhere is a pageaction, but I'm not sure how many pages it's enabled for -- if that icon _always_ shows up, maybe it's not so bad:

If I were an extension developer, I think I'd work around this by modifying the page in question, adding a button for whatever I would've put into a page action. That seems suboptimal, to say the least.

If this isn't an appropriate place to debate the decision, what is? Bugs that bring this up (usually with a specific example) are being deduped to this.

Comment 28 by, May 19 2016

As a user, I find the change surprising. When tons of extensions showed up in my toolbar, I started hiding all the ones I didn't want adding clutter. I hid all the PageActions because I assumed they would still show up in the omnibar when needed. If they don't show up in the omnibar anymore, I will probably uninstall or stop using some of them, because they're not worth the additional clutter if they have to show up all the time or I have to click into another menu to see if they're active on the current page.

Comment 29 by, May 25 2016

I simpathize with Comment 28: If reverting the change is not possible, I would like to share this idea for what I think would be a suitable UX:

"Chrome should determine if the page action icon is already visible and, if not, it should show it within the address bar as in the past. I agree that showing two icons for a page action is a clumsy UX but since Chrome has all information on what is visible in the UI, it should ensure that, for a page action extension, at least one icon appears with withing the address bar or outside. Ensuring that one active page icon is visible further reinforces your goal of security by user awareness and improves usability for clickable page action icons."

Comment 30 by, May 25 2016

With all due respect to who came up with and implemented this change, but it has serious usability and accessibility flaws.

Even for people with no colorblindness, it takes some time to distinguish some of those tiny icons if there are several of them. Not to mention all other problems reported so far.

I might be wrong, but why not keeping the original design (with context specific actions in the omnibar) and just added a (sub)menu listing all the installed extensions with a clearly visible name in addition to the icon? A disabled menu item text is probably a better choice for colorblind users as well.

This would make "unexpected" extensions even more visible, since showing the name is definitely better than an often anonymous or ambiguous icon.

Comment 31 by, Jun 7 2016

The following are examples that probably don't affect "normal" users, but extensions similar to these, which all are variations on showing a page action when javascript errors occur:


One industrious dev allows an alternative mode adding a floating icon on the page

I think this is a very good example of a page action that is not always relevant, since developers would probably only activate it for specific domains.

After spending an hour reviewing this and multiple other bugs and discussions on the forums, I think there exists suggestions for reasonable alternatives that would allow end user awareness of all installed extensions (as was probably the intent) and not _also_ remove page action functionality. There is a middle ground to be achieved.

Comment 32 by, Jun 24 2016

Status: Assigned (was: Untriaged)
Assigning to forg@ per Devlin's advice

Comment 33 by, Jun 25 2016


Comment 34 Deleted

Comment 35 by, Jul 1 2016


Comment 36 by, Aug 8 2016

How about the possibility to allow both a pageAction and a browerAction. The pageAction would be optional and up to the extention whether to show, but the browserAction would be forced like it is now.

This means the user can hide the icon in the menu if they want, but the icon could still appear in the address bar for appropriate pages?

Comment 37 Deleted

Comment 38 by, Aug 11 2016

Any RSS-reader out there would be relevant to the topic. New behavior would be nice as an option in chrome://flags (i.e. it's used by default and previous behavior if user explicitly switches the flag).

Comment 39 by, Aug 11 2016

chrome://flags is for temporary development work, it's not an advanced configuration page that end users should ever be using.

Comment 40 by, Aug 11 2016

Then this option should be in "advanced configuration page".

Comment 41 by, Sep 18 2016

I understand the reasoning behind moving Page Actions out of the address bar, but the change has an unintentional side effect: windows that have window.menubar.visible/window.toolbar.visible property set to false cannot use the page action anymore because of the hidden toolbar. I'm assuming that the page action icon showed up previously in the address bar under these conditions.
Maybe this could be addressed by having the Page Actions show up inside the address bar only when window.menubar.visible is false?

Comment 42 by, Feb 11 2017

This problem persists. If user hides extension icon into the menu, pageAction triggers are not visible to the user.

I think a middle-ground to the current mess would be to automatically show the extension icon into the toolbar when a pageAction is triggered, same to the current "Show in toolbar" right click action. Now as it is, it just overlays a blue dot over an invisible icon hidden inside a menu, -which lets admit- it's not exactly smart.

If the reason for the new design was increased awareness of what is installed, don't let the users hide their extensions in the menu. If hiding in the menu is not a problem, you could easily enforce a toolbar icon for 1st time extension installs,  then let the users hide it and leave the old UI as it was.

I also want to note that chrome  still uses the address bar for internal functionality similar to the old pageActions UI(bookmark star, tab translate, password manager).

Comment 43 by, Aug 11 2017

Page Actions totally should go back to adressbar - saving space (yeah, 15 grayed-out extension icons...), explicitly declaring context (current page and url), justifying Page/Browser Action separation at all, giving more control to users and preserving some cross-browser consistency.

Agree with comment above.

Comment 44 by, Apr 23 2018

A simple solution would be to allow extensions to use both browser_action and page_action at the same time. 

This way users like me could put the main icon hidden in the chrome menu and being aware that an addon is installed and at the same time beneficiate of the extensions buttons in the omnibox when it is needed. 

The toolbar would be less cluttered with unneeded buttons from addon that work only on few websites, it would be a great advantage for users. 

 Technically also it would be very easy to put this solution in place.

Comment 45 by, May 15 2018


Sign in to add a comment