New issue
Advanced search Search tips

Issue 907997 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: [Win-10 (Touch device)]Unable to open Chrome browser context menu on chrome://version page.

Reported by dchau...@etouch.net, Nov 23

Issue description

Chrome Version: 72.0.3618.0 (Official Build) Revision	473cb3615ccd757dbfd816963e699299a0732b59-refs/branch-heads/3618@{#1} (32/64-bit)
OS: Windows-10(Touch device).

What steps will reproduce the problem?
1. Launch chrome and go to chrome://version page.
2. Long tap on blank area to open context menu and observe.

Actual: Unnecessary selection context menu open instead of Chrome browser context menu on long tap.
Expected: Browser context menu should get opened after long tap.

This is a regression issue, broken in M-72 series, below is manual regression range: 

Good build: 72.0.3609.3 (Revision: 607407)
Bad build: 72.0.3610.0 (Revision: 607838)

You are probably looking for a change made after 607795 (known good), but no later than 607796 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/d83381af973e3eff2051e0e8cf424abb44fcd34a..3d2b731cfd6e12c9fcf2cdbddca59243d716e228

Suspecting: https://chromium.googlesource.com/chromium/src/+/3d2b731cfd6e12c9fcf2cdbddca59243d716e228

@xiaochengh: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

NOTE: 
1. This issue is not reproducible on Windows(7, 8, 8.1, 10), Mac (10.13.1, 10.13.6, 10.14.2) and Linux (14.04 LTS) OS.
2. This issue is also seen on Dev #72.0.3610.2

Kindly review the attached screen-cast for reference.

Thank you.
 
Actual behavior.mp4
1.3 MB View Download
Expected behavior.mp4
694 KB View Download
Labels: ReleaseBlock-Dev
Since it is regressed recently also seen in present dev ##72.0.3610.2, adding RB-Dev for tracking purpose.
Please change if it is not required.
Labels: -ReleaseBlock-Dev ReleaseBlock-Stable
Its not a dev blocker.reducing priority.
Components: Blink>Editing>Selection
Long press is supposed to select the closest word, and in some cases snapping is allowed.

But this one seems to be snapping more than allowed...

My patch fixes some issue in word boundary finding, and there are some dependent patches landed, so it shouldn't be a pure revert.

I guess the right level to fix should be in SelectionController. Let me check.
I'm not sure what should be the correct behavior...

In all versions, long tapping the empty area in the left selects "Google" and shows editing context menu.

My patch makes long tapping at the right side similar the last word "Default", which is actually more self-consistent in some sense...

Will discuss with yosin@ later.
Labels: Hotlist-DesktopUIConsider
The behavior about long tapping or double clicking is not specced, and different browsers have slightly different behaviors.

This seems more of a UX issue than regression:

Without my CL:
- Long tapping before a table selects the first word in table and shows selection menu
- Long tapping after a table doesn't select anything and shows browser context menu

With my CL:
- Long tapping before a table selects the first word in table and shows selection menu
- Long tapping after a table selects the last word in table and shows selection menu

So in some sense, my CL improves consistency.

There are three options:

1. Do nothing since the current behavior is self-consistent. However, this might be annoying when there is a very long table, so that long tapping selects something at the bottom of the table that's out of viewport.

2. Disallow long tap selection to cross table boundaries. I'm not quite in favor of this option due to its hacky nature.

Note that we must allow crossing of normal block boundaries, otherwise it would be a much bigger regression.

3. Scroll to selection after long tap. In this way the annoying part of Option 1 is gone.

Adding UX team for more ideas (am I using the right label?)
Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!
Labels: Group-Focus_or_Input
Labels: -Hotlist-DesktopUIConsider Hotlist-DesktopUITriaged
Labels: -M-72 -Target-72 M-73 Target-73
Gentle ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!
I think this issue isn't so sever, and shouldn't be a stable blocker.

1. The original behavior is already inconsistent and half-broken.

2. The issue occurs only when there's a large table

3. This is more of a UX issue

WDYT?
With response to comment #11:
Retested this issue on Win-10(Touch device) using latest Canary #73.0.3652.0 (Official Build) and issue is still reproducible.

NOTE: After long tapping on blank area (as shown in attached video), unnecessary text gets selected and selection context menu opens.

frequency of occurrence the issue:  10 /10

Attaching screen-cast for the same.

Thank you..!
Canary behavior.mp4
677 KB View Download
Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!
Gentle ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!

Comment 15 by jmukthavaram@chromium.org, Yesterday (44 hours ago)

Friendly ping!
Could you please provide an update on this issue as it is marked as RBS and stable release is coming soon.

Thank You!

Sign in to add a comment