Commit-Queue | +1 |
PTAL dmurph@ at the overall implementation (mek@ added as cc for eyes).
There might be some test failures for the redirection cases, but `kScopeA2A` and `kScopeA2B` behavior should be working fine.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +1 |
PTAL dmurph@ at the overall implementation (mek@ added as cc for eyes).
There might be some test failures for the redirection cases, but `kScopeA2A` and `kScopeA2B` behavior should be working fine.
PTAL, handling the build failure locally (should be a simple missing include in the test) and will be uploading everything soon.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dibyajyoti PalPTAL dmurph@ at the overall implementation (mek@ added as cc for eyes).
There might be some test failures for the redirection cases, but `kScopeA2A` and `kScopeA2B` behavior should be working fine.
PTAL, handling the build failure locally (should be a simple missing include in the test) and will be uploading everything soon.
Turns out the failing tests are for redirects, and all other middle clicks seem to work fine. I will disable the tests so that those can be handled while redirects are being worked on.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
// Even though usage of `chrome::FindBrowserWithTab()` is technically not
// allowed anymore, this is needed because sometimes clicks can launch a new
// tab inside an existing window.
The comment seems to be mostly talking about production use-cases, not in tests. So you can probably remove this comment.
// Even though usage of `chrome::FindBrowserWithTab()` is technically not
// allowed anymore, this is needed because sometimes clicks can launch a new
// tab inside an existing window.
same, can remove
"target": "FRAME"
I see the 'link' type is correct here - so perhaps the window.open API doesn't get events like the anchor links do / doesn't get mouse stuff / keyboard stuff?
That's probably OK... but we should maybe investigate what 'aux' style things can actually be sent / read from window.open.
Resolving - it looks like btn window.open links should never hit the aux-click stuff.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Even though usage of `chrome::FindBrowserWithTab()` is technically not
// allowed anymore, this is needed because sometimes clicks can launch a new
// tab inside an existing window.
The comment seems to be mostly talking about production use-cases, not in tests. So you can probably remove this comment.
Done
// Even though usage of `chrome::FindBrowserWithTab()` is technically not
// allowed anymore, this is needed because sometimes clicks can launch a new
// tab inside an existing window.
Dibyajyoti Palsame, can remove
Done
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dibyajyoti PalPTAL dmurph@ at the overall implementation (mek@ added as cc for eyes).
There might be some test failures for the redirection cases, but `kScopeA2A` and `kScopeA2B` behavior should be working fine.
Dibyajyoti PalPTAL, handling the build failure locally (should be a simple missing include in the test) and will be uploading everything soon.
Turns out the failing tests are for redirects, and all other middle clicks seem to work fine. I will disable the tests so that those can be handled while redirects are being worked on.
Flakiness seems to be an unrelated infra failure on CrOS, failed crbug.com/358296948
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
11 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/browser/web_applications/web_app_link_capturing_parameterized_browsertest.cc
Insertions: 0, Deletions: 6.
The diff is too large to show. Please review the diff.
```
```
The name of the file: chrome/test/data/banners/link_capturing/scope_a/start.html
Insertions: 9, Deletions: 12.
The diff is too large to show. Please review the diff.
```
[PWA/Nav Capturing] Add middle click support
This CL adds support for middle clicks to be captured for navigation
capturing by PWAs, as per the behavior outlined in
https://docs.google.com/document/d/176tREY7_qmVsRt15z4q6BRhQyfJAUvy__DmEMDbQ8LI/edit?pli=1#heading=h.3r1ull9cvqat.
Middle clicks simulated and triggered from JS inside a test is
different from "real" user initiated middle clicks based on how
the blink layers parses it to output a NavigationPolicy. To keep
the behaviors consistent, this CL also modifies the existing link
capturing browsertests to use a link click behavior that is
closer to production as much as possible.
WebAppLinkCapturingParameterizedBrowsertest.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
if (!params.browser->app_controller()->ShouldHideNewTabButton()) {
post-land-nit: ShouldHideNewTabButton is not the right way to verify if an app is in tabbed mode or not, as it is possible to have a tabbed PWA without a new-tab button. You probably meant app_controller()->has_tab_strip()?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
if (!params.browser->app_controller()->ShouldHideNewTabButton()) {
post-land-nit: ShouldHideNewTabButton is not the right way to verify if an app is in tabbed mode or not, as it is possible to have a tabbed PWA without a new-tab button. You probably meant app_controller()->has_tab_strip()?
Ack, will fix this in a follow-up CL.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |