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

Issue 39511 link

Starred by 428 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocked on:
issue 39916
issue 42453
issue 54288
issue 137210
issue 166889

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Launch Extension Infobars?

Project Member Reported by finnur@chromium.org, Mar 26 2010

Issue description

Once we are happy with the infobar API and how it works we should consider 
moving it out of experimental. This keeps track of that effort.
 

Comment 1 by finnur@chromium.org, Mar 26 2010

Summary: Move Extension Infobars out of experimental

Comment 2 by finnur@chromium.org, Mar 30 2010

Also remember to remove the experimental startup flags from the get_views and infobars 
API tests.

Comment 3 by finnur@chromium.org, Jun 24 2010

Rafael, will you take this over as well, once you are done with the Linux port? (Mac is in progress)
Labels: -Mstone-6 Mstone-7
Status: Available
Labels: MrBotRecommends
This an automated note...
Recommendations based on labels Feature-Extensions and null from activity in the last 60 days
	aa@chromium.org(Recommended)
	asargent@chromium.org
	arv@chromium.org
	andybons@chromium.org
	mpcomplete@chromium.org
	rafaelw@chromium.org
Status: Assigned

Comment 8 by finnur@chromium.org, Aug 27 2010

Blockedon: 39916

Comment 9 by aa@chromium.org, Sep 13 2010

Labels: -Mstone-7 Mstone-8
We decided to target this for M8.

Comment 10 by aa@chromium.org, Sep 15 2010

Labels: -Type-Bug Type-Feature

Comment 11 by aa@chromium.org, Oct 4 2010

Labels: Mstone-9

Comment 12 by aa@chromium.org, Oct 12 2010

Labels: Mstone-X
What does milestone "X" mean?
Blockedon: 42453
Labels: -mstone-x
Cc: mihaip@chromium.org rahulrc@chromium.org
Issue 90514 has been merged into this issue.
Blockedon: 54288
Cc: kurrik@chromium.org
Labels: -MrBotRecommends Mstone-15
Tentatively targeting this for M15 (see comments on bug 90514).
Some of the bugs this is blocked on are MstoneX, ie.  issue 39916 .

Comment 19 by Deleted ...@, Aug 8 2011

Is there some reason I am getting emails about this?  Can I remove myself from it (beside marking it spam)?  Thanks.
You are probably getting mails because you've starred the issue. Just unstar it and you won't get more emails. 
Labels: -Mstone-15 Mstone-16
This narrowly missed M15, due to painting issues on the Mac. Mike Tsao has been looking into it. Moving to M16.

Comment 22 by laforge@google.com, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17
Cc: miket@chromium.org erikkay@chromium.org
I'm not actively working on this since the only part missing (that I know of) is some Mac polish that Mike was looking into at some point. Should this be assigned to Mike so we don't lose track here?
Cc: aa@chromium.org
I'd say this is Aaron's call at this point.

Mike, could you update the bug with the status of the mac work?
Which polish needs to be done?

Comment 26 by miket@chromium.org, Nov 17 2011

Cc: -miket@chromium.org
I'm removing myself from the cc: field. I was added to see whether there was a certain small change we could do on the M15 cutoff day, but the problem turned out to be bigger (if I recall, the little notch on the top of the alert was ghosting on the Mac).
This is blocking me from switching from Safari to Chrome. It's been open a really long time now, will this be in Chrome 17? What is still missing?

Comment 28 by aa@chromium.org, Jan 20 2012

@27: What specifically would you use this for? Our main concern with this API is that it won't be popular enough to justify the maintenance burden. So if you can give examples of high priority use cases, that would help us a lot.

Comment 29 by cos...@gmail.com, Jan 20 2012

@28: I have an extension for helping people stay focused (it implements the Pomodoro method). I did some work on it last year, and I've waiting for infobars to come out of experimental so I can put it on the market. You can get it here, if your Chrome has the right flags flipped. http://time.pwnb.us/

I started this as a side project in March 2010, when it seemed like infobars were close to being launched. Then I stopped working on this when the infobar extension stopped getting love, so it's a proof of concept that lacks polish. I'd still like to get this launched and improved, though.

~ developer of Clutter: https://chrome.google.com/webstore/detail/fopmmgbckkdhedhndlebkfnocagpgmnc
@28: The use case that's blocking me is LastPass / 1Password support. In Safari the extensions use an infobar, in Chrome they inject HTML into the page, which looks unbearable and sometimes even breaks the page.

Other use cases might be 3rd-Party translation extensions (since Google Translate has an infobar)

Another extension that uses an infobar in Firefox is Web Developer (https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm)

I just looked in the Chrome Store, LastPass has > 300k users, Web Developer too.

All in all, infobars are IMO a valid/important UX pattern, as demonstrated by the use in Chrome-native, explicit support in Safari and usage by Firefox extensions and I'd like to see that pattern accessible to extensions and not only Chrome-native.

Comment 31 by fam....@live.nl, Jan 20 2012

Although I don't know if the other AdBlock devs still want it (over a year has passed since it was suggested and a lot has changed in the mean time; for me personally it's still valid), but we also have issue adblockforchrome:2177, awaiting this issue.
I personally think there will be a lot of extensions that can use infobars, in very different ways.

Comment 32 by nz7...@gmail.com, Jan 20 2012

I have agree with @28. The Lastpass infobars are just so cheap and horrible
Not only LastPass and Adblock, but also Reddit Companion! It's the official reddit.com extension with over 72,000 users, and it has to create a poor facsimile of an infobar.

Plus, the adage "if you build it, they will come" surely applies here. In the beginning, Chrome Extensions with browser action buttons weren't thought of as high-priority enough to demand release or maintenance, and look at them now!
@28 LastPass very much wants this -- to safely allow things like Form Fill buttons in a page (that the original page can't touch) we have to do horrific things like dynamically add iframes to the page.

This is a chrome security issue too, I'd bet most people rolling their own infobars into the page's DHTML don't realize that the page itself can call into their injected infobar type menus and doing it in iframes is a lot more work -- why force developers to roll something on their own that you know is going to create a security problem?

This is the only way to make an infobar that doesn't looks like a cheap knock off of the one you get to use for your own purposes, that opens closes and exists at the top of the page properly. 

Safari has it.
Firefox has it.
With IE you can make your own that's equivalent.

That just leaves chrome.   

Comment 35 by aa@chromium.org, Jan 21 2012

Reddit Companion! Well, why didn't you say so good sir?

In all seriousness, thanks for the enthusiasm people. We'll try and find someone to take this over the finish line soon.
So as this is still tagged Mstone-17, can we expect it in Chrome 17?

Comment 37 by aa@chromium.org, Jan 27 2012

Cc: -andyb...@chromium.org
Labels: -MovedFrom-16 -Mstone-17 Mstone-19
Owner: ----
Status: Available
Sorry, but no. It's way too late for M17, or even 18. But we will try for 19.

Comment 38 by laforge@google.com, Mar 27 2012

Labels: -Mstone-19 Mstone-20 MovedFrom-19

Comment 39 by aa@chromium.org, Mar 28 2012

Labels: -Mstone-20 -MovedFrom-19
So is this now targeted for M19 or M20 or ...?

Comment 41 by aa@chromium.org, Mar 29 2012

Neither. I shouldn't have committed above to a milestone until there was actually someone who could work on it. Wishful thinking.

But it is on the shortlist of features to do "soon". There just isn't any point assigning a milestone until there is someone to do the work.
It's really disappointing how this so much requested feature is being neglected for years now.
I can help if you are in a "shortage" of hands for this, I could try to submit a patch for that and start the wheel ... 
FWIW: Last I heard there was some weird painting issue with infobars on Mac.
> FWIW: Last I heard there was some weird painting issue with infobars on Mac.

Is it considered a "blocker"?
Painting glitches for this feature on any platform would be considered a blocker, yes.
So can anyone actually confirm the painting issues? I haven't seen them in my (limited) experiments.

What info do you need to either confirm or refute the existence of these painting issues?

Comment 48 by aa@chromium.org, May 19 2012

Cc: koz@chromium.org kalman@chromium.org
+kalman, koz ... I think one of you was looking at this and thought there was a ways to go. Can you expand?
The painting also looks bad on Linux.  I haven't tested Windows.  Mac certainly looked bad.

There were a few issues like the infobar offset from the top being a pixel or few off, and bad indication where the infobar came from.  The larger issue is just that it doesn't look like part of chrome; this comes from allowing arbitrary HTML inside the infobars.  They just look big and clunky and slow.

IMO this API needs a bit of rethinking, but yeah, at minimum we'd need to fix those offset and related issues.
Still, extensions that try to duplicate what a true infobar could give us are clunkier, slower, less secure, and they don't even look similar, let alone like they belong in Chrome. For some big-name examples, see LastPass and Reddit Companion.
Hm, fair enough.

I would love to get away with removing the arbitrary HTML feature and just provide a context-menus style API where the infobar is built up with buttons and callback and stuff, since it would let us do cool things like granting the currentTab permission when buttons are clicked, and enforcing that it doesn't look terrible.  I don't know whether this is reasonable.

But that's what I meant when I said "rethinking".

Comment 52 by cos...@gmail.com, May 22 2012

@51: I really like the freedom of having HTML in the infobar, it gives us more flexibility. For example, my extension doesn't use a button, it uses a drop-down instead.

I don't think you should worry about developers producing ugly info-bars. We (devs) know an aesthetic UI is perceived as a more usable UI, and the users will choose the extensions that integrate well with Chrome anyway.

I would be happy to see some built-in CSS, and a recommended markup template. This way, we have a good default style to use, and we have the flexibility of deviating from the default if needed.

Thank you very much for taking a look at infobars! I really hope to see them finalized!
What is the status of this issue please? I see that all the blockers are fixed now.

Thanks.

Well, as discussed above, I think the Mac painting issue is a blocker. I experienced this myself - filed  bug 137210  for this. Hopefully this can be fixed soon so the API can be finalized ASAP. Thanks.

I wrote the original Reddit extension ( http://marvin.cat-v.org ) that used the original 'toolbar' API which was removed with the big extension API redesign that happened before extensions became official.

Anyway, been waiting for years for the functionality to be restored.

@51 I would also love if you removed the arbitrary HTML feature, and instead have a context-menus styles API. Is really the only way to make sure infobars feel integrated properly with the rest of the UI and act consistently, otherwise every extension will provide very different and clumsy UI.

People used to web development or who have hacked up their own bars using content scripts will want raw HTML support, but I think it would be a mistake. 
Any news?...
Cc: -mihaip@chromium.org
Blockedon: chromium:166889
Cc: gauravsh@chromium.org
Cc: stephenlin@chromium.org
Cc: leecy@chromium.org
Cc: joshwoodward@chromium.org
Labels: Feature-ECHO
Project Member

Comment 65 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Feature-Extensions Cr-Platform-Extensions Cr-UI
Labels: Cr-OS-Goodies
Labels: -Feature-ECHO -Cr-OS-Goodies Cr-Marketing-Goodies
Is there any hope for this?  Issue 137210  hasn't been getting any love. Is it not considered important even after all the extension creators chimed in? Surely the content injection people have to do to create makeshift infobars can't be better than slightly quirky infobars with edge rendering issues.
We will have a notifications API in stable soon-ish.

http://developer.chrome.com/extensions/notifications.html

hopefully that will solve all notification use cases that infobars would usually solve.

The other use case I hear for infobars, namely to implement toolbars, is just generally a bad idea. I am tempted to mark this bug WontFix and just put everybody out of their misery.
> The other use case I hear for infobars, namely to implement toolbars, is just generally a bad idea.

Why?

An infobar isn't the right idiom, and toolbars are annoying.

Comment 72 Deleted

Extension developers have a use case for infobars just like the Chrome developers do. https://support.google.com/chrome/answer/173424?hl=en

Comment 74 by cos...@gmail.com, Jul 8 2013

If the notification is specific to a page and not time-sensitive, it seems to me that an infobar is better than a system tray notification. 
Yes fair point. We've talked earlier about what a toolbars API would look like, and embedding HTML into something at the top of the page really isn't a good solution.
- It's almost guaranteed to look bad.
- In most cases, to do anything useful to the page the extension will need to request all-urls anyway.

We would probably offer something more along the lines of the notifications API where there is a set structure an extension can request.
... and which works with activeTab.
> Extension developers have a use case for infobars just like the Chrome developers do.

Well, since you mentioned that I thought I should point out that there is an effort underway to cut down on the number of infobars that Chrome displays.
> there is an effort underway to cut down on the number of infobars that Chrome displays

Even so, it's important to keep talking about this. The current solution most extension developers fall back to is injecting markup into the DOM of the active tab, which IMHO is an awful solution.

LastPass is a great example for this: it needs to show an infobar within the context of the page that's more prominent than a mere page action, because when it is shown the user is most likely going to want to use it.

Comment 79 by v...@longstorm.org, Jul 11 2013

Exactly, if you kill infobars I'll just mimic their behavior with injected, far from secure html and then I (and other extension authors) will have to worry about breaches.

Besides, if infobars are killed yet Google Translate still has privileged access to that 'idiom', I'd be very disappointed. Why should Google Translate have privilege over other potential translation APIs in an open source project? Especially when it's now charging for developers to use it's API, so Google Translate is not even in the 'public good service' section anymore.
Google Translate isn't an API nor implemented as an extension, it's built into chrome. 

However I do loosely agree that we should give extension authors the ability to show infobars; as Finnur said, Chrome UI is trying to cut out infobars, *however* that's not necessarily a good reason to not allow extensions to show them. Let the free market decide whether it prefers an extension which shows an infobar or doesn't.

I'm actually idly considering whether we want two separate APIs here, both an infobars API and a toolbars API, the former restricted but with infobar behaviour and working nicely with activeTab etc, the latter just HTML content. Better the devil we know.

Anyway stay tuned, I suppose.

Comment 81 by v...@longstorm.org, Jul 11 2013

And just to be clear, my use case isn't either here nor there (not a notification, not a toolbar.) In fact, the Google Translate bar isn't either. It's a context-based, one-off action. It appears when a certain condition is met, and then the user can dismiss it, take an action, or leave it there to take the action later. That's a use case that, if infobars are removed, will only be fulfilled with custom injected html. And it doesn't need to be that way.
We will soon have the declarative content API which is potentially a nice fit here.
Labels: Restrict-AddIssueComment-EditIssue
Also: The bug tracker is a tool for project members to track tasks and their status, not a tool to argue about the merits of a given feature. That just adds noise, which slows down the team members working with the issues and is therefore unhelpful. Restricting comments.
Summary: Launch Extension Infobars? (was: Move Extension Infobars out of experimental)
r214692 moved this from experimental to restricted-to-trunk. We still need to decide if we want to launch it to stable.
Cc: -gauravsh@chromium.org
Cc: -leecy@chromium.org -stephenlin@chromium.org
Labels: -Cr-Marketing-Goodies
Status: WontFix

Sign in to add a comment