Thanks for the report.

Considering this as Feature request and marking as Untriaged, requesting Dev team to check the issue.

A right-click option in the omnibox sounds like a reasonable approach to consider.

I'm not sure I understand the proposed behavior with the omnibox. The right-click context menu for the omnibox would just show a list of tabs that were recently closed in *other* profiles? That feels a little unintuitive to me.

No, it would allow you to re-open the currently-displayed tab in a different profile.

Presumably, we'd add an "open link as >" submenu to the omnibox context menu in the same cases as we add that submenu to context menus on links in webpages.

Though we might want different strings.

All that said I'm a bit iffy on the value of this.  I think we should only do this if we think it will have similar usage as to the menu options on links in the content area.  I would be surprised if this came within an order of magnitude of those.

So I think you are basically trying to compare and gauge:
1. How often multi-profile users need to *switch* profile when opening links *inside* the browser, versus:
2. How often multi-profile users need to merely *open* URLs from *outside* the browser.

Am I rephrasing correctly?

I think the answer depends for the most part on whether people use some Webmail service or not. I agree this feature wouldn't be very useful to Webmail users. On the other hand, 2. is actually *more* frequent than 1. for people using a native mail client. That's very many "enterprise" users.

I don't know if that's what I was trying to compare, but it's very useful that you cite a specific practical use case like this.

This sounds to me like the proposed workaround is still frustrating:
* All your mail links still open in the wrong profile,
* And you have to already have the right profile open,
* And then every single link you have to manually move over.

It sounds like instead we should try and ensure that external handlers can do more than just "invoke Chrome", but "invoke this Chrome profile", so that your native mail client can simply open the correct Chrome profile.  At worst, we'd do this by providing some sort of script/batch file to start Chrome with the right options, then associate with that; at best, Windows would allow handlers like HTTP to pass along command-line args when executing some shell action.  The tricky part would be figuring out the UI for where to put this.  Maybe the separate Chrome profiles should show up as separate items in the "associate with" dialog you get at the system level.

Agreed opening with the right profile in the first place would be a better solution. Afraid this would be a *much* longer term solution... if at all. Among others it would require some sort of "right-click->Open with..." two-level support in all native email clients and other applications, correct? Some may never be interested in implementing that.

If you want links opened from app A to open in Chrome profile 1, but app B to open in Chrome profile 2, then you probably are indeed out of luck.

If you want links on the system to open in 1 but they're opening in 2, that's the thing that seems fixable, and would not require support from other clients.  Though in that case I'm curious how you get in a scenario where you want everything to open in a particular profile that's not the default profile.

Maybe the answer in that case is a simple piece of UI in Chrome to make some particular profile the "default" profile.

All native email clients support multiple email accounts; there's "no app B". The main use case is unique email app A opening some links in profile 1 and some other links in profile 2 with no automated way to tell. Only the user knows which profile by looking at each link (just like for the 1191453002 use cases).

One current workaround is to close the tab opened in the wrong profile, re-arrange profile windows so the correct profile is on top and on the current screen, go back to the email message, cross finger and click again.

If I want to open some links from the same program in different profiles, I find the easiest way is to drag the links from the mail program to the different windows' tabstrips.  I've used that mechanism for a couple of years.

If that's the use case, though, then there's no easy way to solve this at the app registration level.  However, a script or Chrome extension that automatically direct links to one profile or another based on e.g. regex/string matching might be sufficient.  (For example, tell the extension to send all links to mycompany.com pages or Google Apps to profile A, and everything else to profile B.)

> I find the easiest way is to drag the links from the mail program to the different windows' tabstrips

An IMHO faster and more convenient alternative, especially for "full-screen" users would be to... implement this feature request. Came full circle :-)

I admit that my gut reaction to the idea of someone opening links in multiple simultaneous Chrome profile that are each fullscreened on the same monitor is "don't do that" :)

I do think the script/extension route may be better.  Can such a thing theoretically be written today or do we lack sufficient APIs for it?

Usability and speed discussions aside, drag'n'drop assumes enough screen real estate for the third party app + one chrome window for each profile. Which means more than enough screen real estate for just the chrome profiles so what was the point of "Open as..." 1191453002 then? Do you think it was a mistake too?

I think we're getting a little off-track if we're trying to re-litigate bug 103073.  My argument here was that I'm concerned about whether the utility of this proposal is remotely as high as what we added for that bug, and we're not really answering that.  My suggestion to address the core use case here was to check whether we have sufficient APIs to make an extension or script for this, and avoid forcing users to manually deal with it on every single link click, and we're not really answering that either.

> My argument here was that I'm concerned about whether the utility of this proposal is remotely as high as what we added for that [103073 and not accessible] bug 

I think I answered this one in comment #9: for some categories of users, notably the ones using a native email client, this 739546 feature would solve a *more frequent* use case than what 103073/1191453002 already solved. This is from first hand + shared experience and the exact reason I came and filed this request. Granted: compared to the less frequent 1191453002 use case there would be the small "frustration" of just one extra and spurious click. Still vastly better than today ("Perfect the enemy of good").

> My suggestion to address the core use case here...

If realistic then such a better solution would indeed invalidate this "re-open as" request. In any case I think another "bug"/feature request would be a clearer and better place to discuss it.

>... we're not really answering that either.

Past the use case description I'm afraid I don't have any ideas or knowledge to offer there.

In fact "Re-open tab in Incognito mode" would be useful too because right-clicking is not always available as a way to navigate further.

- There are some menu implementations that you cannot right-click on, for example some menus on https://www.amazon.com/
- Many sites load new content when merely scrolling down, so no right-click option there either: https://plus.google.com/communities/113130687555589110223

> Opening with the wrong profile happens all the time when opening an URL from another application than the browser itself.

The tedious way I usually work around this issue is by making sure a Chrome window with the correct profile is stacked on top of all other Chrome windows. To achieve this I simply click on said window *before* opening the link. This is tedious and inefficient because it involves a fair amount of window shuffling but it's the least painful I found so far.

This workaround unfortunately breaks when Chrome windows (with different profiles) are spread across multiple monitors and do NOT overlap. Then clicking on a window doesn't seem to put it "virtually on top", some other one stays prioritized... Any idea why? More generally speaking how does Chrome select which window gets to open the URL passed from an external handler?