+ortuno

Yes I suggest we change the order (move to 4th row). The 'open link in {app}' menu seems to create inconvenience especially in the browser context. 

A new assumption for us would be that the menu item is still easily recognizable by the icon even when it's moved to the 4th row in the menu, i.e. less discoverability trade-off of changing the order.

"if you've installed an app then being in that app's window is your preferred way of using that site."
I think in this case it was a pre-installed app so this isn't a strong signal of the user's intention in general.

#3 OK let's change the order.

#4:
> I think in this case it was a pre-installed app so this isn't a strong signal of the user's intention in general.

This only triggers if it's a) a PWA and b) set to open in a window. In this case I believe the app was G+ which isn't a PWA and isn't set to open in a window, so I don't think this was a default-installed case.

Arguably, if there's a default-installed PWA set to open in a window, that is a strong signal of *our* intention that the app's window is the preferred way of using that site, so even if the user hasn't explicitly opted into it, we've decided to set up the system as if they did.

Seems simple enough. I'll do it.

CLs:
1. https://chromium-review.googlesource.com/1345753
2. https://chromium-review.googlesource.com/1345754

Screenshot of the new position on the context menu (after "Open in incognito tab").

Deleted: new-context-menu-position.png 18.2 KB

	new-context-menu-position.png 18.2 KB View Download

Thanks!

And yeah: I use "open in new tab" all the time (it is probably my most-used menu item overall), so having it move was a surprise.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/67b3b7aaeb8340a19d677bc27738c6a59b13bced

commit 67b3b7aaeb8340a19d677bc27738c6a59b13bced
Author: Matt Giuca <mgiuca@chromium.org>
Date: Thu Nov 22 06:46:21 2018

Refactor link context menu code to avoid duplication.

Instead of two separate code paths for when the Desktop PWAs flag is
enabled/disabled, it's now a single code path that makes a few
behavioural changes depending on the status of that flag.

Bug:  907298 
Change-Id: I6b449fd65390d631098b2bc58e6c1ea668d5fd41
Reviewed-on: https://chromium-review.googlesource.com/c/1345753
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Matt Giuca <mgiuca@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610323}
[modify] https://crrev.com/67b3b7aaeb8340a19d677bc27738c6a59b13bced/chrome/browser/renderer_context_menu/render_view_context_menu.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/41a9e47deedeb97d5d46e2cdae288e0036750a3c

commit 41a9e47deedeb97d5d46e2cdae288e0036750a3c
Author: Matt Giuca <mgiuca@chromium.org>
Date: Fri Nov 23 00:59:49 2018

Move "Open link in <app>" lower down on the link context menu.

Makes it not so prominent (after "open in incognito" rather than being
the topmost item on the menu).

Bug:  907298 
Change-Id: I74997f18a7b6bb39db1210912ed1f40e69a4fffe
Reviewed-on: https://chromium-review.googlesource.com/c/1345754
Commit-Queue: Matt Giuca <mgiuca@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610509}
[modify] https://crrev.com/41a9e47deedeb97d5d46e2cdae288e0036750a3c/chrome/browser/renderer_context_menu/render_view_context_menu.cc

Verified the fix on Mac 10.14.1, Windows-10 and Ubuntu 14.04 using Chrome version #72.0.3619.0 as per the comment #0.
Attaching screen shot for reference.
Observed the "Open link in <app>" is lowered.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on chrome version with out fix.

Thanks...!!

Deleted: 907298 CL.png 1.1 MB

	907298 CL.png 1.1 MB View Download