Issue metadata
Sign in to add a comment
|
Regression: Unwanted highlight is seen on 'Cast desktop' even if 'Cast tab' option is selected.
Reported by
db...@etouch.net,
Oct 25 2017
|
||||||||||||||||||||
Issue descriptionChrome Version: 63.0.3239.18 Revision 975787a36cf8dbe16eaf42134aaee20fe9504ba2-refs/branch-heads/3239@{#188}(32/64 bit) OS: Windows(10 Touch device) What steps will reproduce the problem? (1) Launch chrome, Tab on Wrench menu and select 'Cast' option. (2) Tab on 'View cast mode list' icon, select 'Cast tab' option. (3) Again tab on 'View cast mode list' icon and observe highlight. Actual: Unwanted highlight is seen on Cast desktop even if 'Cast tab' option is selected. Expected: Highlight should seen properly. This is a Win 10 touch device specific regression issue broken in 'M63' and below is the bisect info Good Build: 63.0.3209.0 Bad Build: 63.0.3210.0 You are probably looking for a change made after 500506 (known good), but no later than 500507 (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/03ae8b26cac782874390cadc5fd5faa6025cf5ba..e976a3897d7a8abbbacce4c2622cc5ecf5a7b067 Suspecting: https://chromium.googlesource.com/chromium/src/+/e976a3897d7a8abbbacce4c2622cc5ecf5a7b067
,
Oct 26 2017
Fixing component.
,
Oct 30 2017
Just to update, still bale to reproduce the issue on build 64.0.3253.0 on Windows 10 touch device, Issue is tagged with a stale blocker for M63. Can this be addressed. Thanks.!
,
Oct 30 2017
[Bulk Edit] URGENT - PTAL. M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you.
,
Nov 6 2017
M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge to M63 ASAP. Thank you.
,
Nov 7 2017
dbbrooks@ and I did some follow up here. We can repro this on Chrome 64, but also on Chrome 62. I don't know if the revert change noted in the description was also pushed back to Chrome 62 or something else, but the current actual behavior seems to have been in place for some time. (leaving it tagged as a regression for now, but if the reporter can also repro in earlier versions I would suggest changing to a standard bug) It does feel like something is odd with the touch targeting, something like touch events last a little bit longer than expected and so propagate down to the next element underneath what ever was just touched if the first element was dismissed by the touch. But this isn't a stable blocker and feels at best to be a P2 as it's a visual annoyance but doesn't impact functionality otherwise, updating labels accordingly.
,
Nov 7 2017
Agree that this should not be flagged as stable blocker.
,
Nov 7 2017
,
Mar 30 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Oct 25 2017