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

Issue 897676 link

Starred by 1 user
Status: WontFix
Owner:
kristip...@chromium.org
Closed: Oct 24
Cc:
yyushkina@chromium.org
nyerramilli@chromium.org
rbasuvula@chromium.org
█ ramyan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression:[NTP]'Can't Create shortcut' confirmation message is not displayed on creating duplicate shortcut

Reported by vineetha...@etouch.net, Oct 22 
Chrome Version: 72.0.3588.0 (Official Build) Revision 56533f367ba451d6545ab0045e8e11f288b36326-refs/branch-heads/3588@{#1}(32/64-Bit)
OS: Windows(7,8,8.1,10), Mac (10.13.1, 10.13.6, 10.14.1) and Linux (14.04 LTS)

Pre-condition: Enable "Enable using the Google local NTP" ,"New Tab Page Background Selection" and "New Tab Page Custom Links" flags under chrome://flags.

Steps to reproduce:
1.Launch chrome ,navigate to NTP and add a shortcut by clicking on 'Add Shortcut' button.
2.Now add another shortcut with the same URL used for the previously added shortcut and observe the confirmation message.

Actual Result  : 'Can't Create shortcut' confirmation message is not displayed.
Expected Result: 'Can't Create shortcut' confirmation message should be displayed on creating a new shortcut using existing URL.

This is a regression issue, broken in 'M-71', and below is the bisect info:
Good Build:71.0.3575.0 (Revision: 597883)
Bad Build :71.0.3576.0 (Revision: 598282)

You are probably looking for a change made after 598166 (known good), but no later than 598167 (first known bad).
CHANGE-LOG URL:

https://chromium.googlesource.com/chromium/src/+log/41ef4d66feba41eca74cf23ebdf4e9560bb27939..a5141b9635cb0545ee6814bd3769c0377159b8f2	

Suspect: https://chromium.googlesource.com/chromium/src/+/a5141b9635cb0545ee6814bd3769c0377159b8f2

@kristipark: 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.

Thank You!
ActualVideo.mp4
557 KB View Download
ExpectedVideo.mp4
530 KB View Download

Comment 1 by kristip...@chromium.org, Oct 22

Cc: yyushkina@chromium.org
This is WAI, but is probably confusing to the user. The first URL was added as https, but was changed to http after the HEAD request finished (e.g. flash and color change). The second URL was also added as https, but could not be changed to http since the http version already exists in the list.

So now there are two versions of the same URL with different schemes, which isn't very visible to the user unless they examine the link either by hovering (and looking at URL that appears in the bottom left corner of the browser) or clicking edit shortcut.

Comment 2 by yyushkina@chromium.org, Oct 22 

That is confusing to the user. Should we ignore schemes when comparing URLs?

Comment 3 by kristip...@chromium.org, Oct 23 

That will probably become a source of multiple corner cases (i.e. distinguishing our HEAD request modification vs a user edit, having a user edit that changes from https to http using the edit dialog, etc). IMO, the HEAD request itself has introduced multiple bugs and doesn't feel very graceful, so I'm hesitant to add more onto it.

Comment 4 by twelling...@chromium.org, Oct 23

Labels: zine-triaged

Comment 5 by kristip...@chromium.org, Oct 24

Status: WontFix (was: Assigned)
The HEAD request will be removed for M72 (see bug 874194)
►

Sign in to add a comment