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

Issue 836757 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
OOO Jan 14 - 25
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: Unnecessarily URL is seen on tab strip instead of New Tab text label after running Audit in DevTools

Reported by khushal....@etouch.net, Apr 25 2018

Issue description

Chrome Version: 68.0.3406.0 (Official Build) Revision	80672a4583963b6aa35cb10e9c629bb8638057c2-refs/heads/master@{#553301} (32/64-bit)
 
OS: Win(7, 8, 8.1, 10), Linux(14.04 LTS) and Mac(10.12.6, 10.13.1, 10.13.4).

Steps to reproduce:
1. Launch Chrome and open DevTools on NTP.
2. Now Run Audit and observe the tab strip.

Actual Result: Unnecessarily URL is seen on tab strip instead of New Tab text label. 
Expected Result: New Tab text label should be seen on tab strip instead of URL. 

This is Regression issue broken in 'M-64’ and Using the per-revision bisect providing the bisect results,

Good Build: 64.0.3267.0 (Revision: 515868)
Bad Build:  64.0.3268.0 (Revision: 516147)

You are probably looking for a change made after 516132 (known good), but no later than 516133 (first known bad).

CHANGE-LOG 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/599b5bf5e68612a03f3af06304ae37c74ee19112..5b4a0cb6c9f73c4c27bddd6909706452cf2cd47e

Suspect: https://chromium.googlesource.com/chromium/src/+/5b4a0cb6c9f73c4c27bddd6909706452cf2cd47e

@avi: 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: Issue is also seen on M-66 Stable & Beta (build #66.0.3359.117) and M-67 Dev (build #67.0.3396.19).

Kindly refer attached screen cast.

Thank You..!!

 
Actual Video.mp4
926 KB View Download
Expected Video.mp4
893 KB View Download

Comment 1 by a...@chromium.org, Apr 30 2018

Cc: a...@chromium.org
Owner: dgozman@chromium.org
That change indeed altered how document titles work, but it was fixing something that was broken. If running a DevTools audit resets the document title, that's a DevTools issue.

Passing to the DevTools folks. Let me know if there's anything I can do to help.
Owner: phulce@chromium.org
Patrick, mind taking a look?

Comment 3 by phulce@chromium.org, Apr 30 2018

Audits isn't reseting the document title, the order of actions is:

Navigate to about:blank
Navigate to URL (i.e. https://www.google.com/_/chrome/newtab?ie=UTF-8)
Navigate to about:blank
Go offline
Navigate to URL (i.e. https://www.google.com/_/chrome/newtab?ie=UTF-8)

It seems that when navigating to the new tab page while offline the title does not get relabeled to 'New Tab' in the same way that it does while online (and neither does the page itself as you can see from the videos). If this is inline with the expected behavior from the change avi@ described, we don't have a problem with it; safe to close.

Comment 4 by a...@chromium.org, Apr 30 2018

Cc: phulce@chromium.org
Owner: treib@chromium.org
The search tab helper plays funny games with titling the NTP. NTPs have no inherent page title, but when they finish loading they're stamped with the proper title.

search owner, can you comment?

Comment 5 by treib@chromium.org, May 2 2018

Cc: kristip...@chromium.org treib@chromium.org
Owner: ramyan@chromium.org
Over to new NTP owners.

We've had multiple issues with the title mangling before. AFAIK the reason for the whole thing is i18n: We want the title to be in Chrome's UI language, but the user's Google search language (= remote NTP language) may be different, so the page can't set the proper title.
Probably SearchTabHelper will need to listen to some additional page load event and also set the title there.

(Side note: This is one of the problems that just goes away with the local NTP.)
Cc: yyushkina@chromium.org kmilka@chromium.org
Labels: -Pri-1 Pri-3
Thanks for the additional context Marc!

+Yana to comment on expected behavior, as mentioned in comment #3.

Since this a regression that has existed for a while, and given the more pressing work being done on the NTP for the M69 timeline, I'm reducing the priority of this bug.
Components: -Platform>DevTools
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
Mass UI Triage Update:

Still able to reproduce the above issue on Win(7,8,8.1,10), Linux(14.04 LTS) and Mac(10.13.1, 10.13.4, 10.14.2) OS using latest canary #72.0.3609.3 .
Please find the screen shot for reference.

@ramyan: Could you please take a look into this issue.

Thank you
Canary_Behaviour.mp4
1.0 MB View Download

Sign in to add a comment