New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 896040 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 876280
Owner: ----
Closed: Oct 18
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

[User Feedback - Stable] After exiting a search on the settings page, highlighted state for results remains

Project Member Reported by craigtumblison@chromium.org, Oct 16

Issue description

Chrome Version: 69.0.3497.100, 70.0.3538.67
OS Version: OS X 10.13.6

What steps will reproduce the problem?
1. Open chrome://settings
2. Search for "p" (allowing results to highlight on that page)
3. Wait a few moments
4. Click the "X" to end the search
5. Notice that the yellow tooltips remain present

Video: https://www.youtube.com/watch?v=rgPHSZwDAng

What is the expected result?
The tooltips / highlighting should disappear.

What happens instead of that?
The tooltips / highlighting continue to appear.

This was flagged by our community experts as a likely bug. Not sure if it could be tackled as part of bug 719764 but wanted to flag regardless :)

Thanks!
 
Summary: [User Feedback - Stable] After exiting a search on the settings page, highlighted state for results remains (was: After exiting a search on the settings page, highlighted state for results remains)
Can you open the dev tools and see if there are any errors there (and paste them in this bug)?
Cc: vamshi.kommuri@chromium.org
Labels: -Type-Bug -Pri-3 ReleaseBlock-Stable Triaged-ET Target-70 RegressedIn-69 M-70 FoundIn-70 Needs-Triage-M70 hasbisect OS-Linux Pri-1 Type-Bug-Regression
Able to reproduce the issue on reported chrome version(s) 69.0.3497.100 and 70.0.3538.67 using Windows 10, Ubuntu 14.04 and Mac 10.13.1
The issue seems to be fixed on the latest canary 72.0.3582.0

Bisect Information:
--------------------
Last Bad Build:  70.0.3538.67
First Good Build:71.0.3539.0

We are facing error(Perf builds....) while running the per-revision bisect and even running chromium bisect, that neither helped as we ended up getting all good builds. Hence providing change log from omahaproxy.
https://chromium.googlesource.com/chromium/src/+log/70.0.3538.0..71.0.3539.0?pretty=fuller&n=10000

Requesting someone from respective team to help in assigning it to the right owner.
As this seems to be regressed in M69, adding RBS for M-70. Please change/remove if required.

Thanks!
Labels: -ReleaseBlock-Stable
#2: Sure! Here's the devtools output. In total, 3 warnings and 1 error.

Warnings:
[Deprecation] HTML Imports is deprecated and will be removed in M73, around March 2019. Please use ES modules instead. See https://www.chromestatus.com/features/5144752345317376 for more details.
polymer-micro-extracted.js:442 [Deprecation] document.registerElement is deprecated and will be removed in M73, around March 2019. Please use window.customElements.define instead. See https://www.chromestatus.com/features/4642138092470272 for more details.
(anonymous) @ polymer-micro-extracted.js:442
polymer-mini-extracted.js:2083 [Deprecation] Element.createShadowRoot is deprecated and will be removed in M73, around March 2019. Please use Element.attachShadow instead. See https://www.chromestatus.com/features/4507242028072960 for more details.
_createLocalRoot @ polymer-mini-extracted.js:2083

Errors:
crisper.js:24 Uncaught Error: Assertion failed: An associated control was expected for SETTINGS-SUBPAGE Edit person, but was not found.
    at assert (crisper.js:24)
    at revealParentSection_ (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)
    at doSearch (crisper.js:481)


#3: Thanks for the help! Just to confirm, this didn't regress in M69 (I was able to repro in M68 too). It's also probably not a RBS, so removing that for now :)

I'll loop back with the expert that reported this and see if they can confirm it being fixed in Canary.

Thanks!
Cc: scottchen@chromium.org
craigtumblison@: Thanks, the error is definitely the reason this behavior is observed.

To me this seems fixed by https://chromium-review.googlesource.com/c/chromium/src/+/1198006, which is r587862 and probably a duplicate of  issue 876280 .
Mergedinto: 876280
Status: Duplicate (was: Untriaged)
Awesome, that makes sense to me, and would explain why it appears fixed on canary already.

Marking this as a dupe for now.

Thanks for the help!

Sign in to add a comment