New issue
Advanced search Search tips

Issue 768595 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 779414
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

drag of URL with a long title to desktop folder fails

Project Member Reported by wfh@chromium.org, Sep 25 2017

Issue description

Chrome Version: 63.0.3223.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
OS: Windows 10

What steps will reproduce the problem?
(1) Visit a URL with a long title e.g. https://www.amazon.co.uk/dp/B074DVPCVJ
(2) Drag the url from the omnibox to a desktop folder
(3)

What is the expected result?

.url file is created

What happens instead?

no .url file is created.

Please use labels and text to provide additional information.

Perhaps the title is reaching the maximum filename size, and it should be cropped?

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Owner: jdonnelly@chromium.org
Status: Assigned (was: Untriaged)
Verified and investigating.
Components: -UI>Browser>Omnibox Internals>Views
Owner: ----
Status: Untriaged (was: Assigned)
This issue is not specific to the omnibox, removing UI>Browser>Omnibox.

For example, if I go to the following page:
https://www.amazon.co.uk/s/ref=nb_sb_noss?url=search-alias%3Dlighting&field-keywords=Portable+LED+Camping+Light%2CFOGEEK
I can drag most of the links on that page to the desktop and .url files are created. But if I drag the link to the page from the original report ("Portable LED Camping Light,FOGEEK [Power Bank] 5 Adjustable Modes [...]") nothing happens.

My guess is that this is caused by the Windows limit on file length and when the link we try to create violates it, it fails silently. This is just a guess, but I think what's necessary is to limit the length of data.url used in Widget::RunShellDrag() or somewhere downstream of there:

https://cs.chromium.org/chromium/src/ui/views/widget/widget.cc?l=784&rcl=f26dc9e577e66ad595b82e9fce4bec8861ef89cd

Finally, note that I reproduced this issue in both [63.0.3223.8 (Official Build) canary (64-bit)] and [62.0.3202.29 (Official Build) beta (64-bit)] and that it's probably not a regression.
Correction, I meant to say the title in the OSExchangeData objection, not the URL.
Oh, brother. Correction, I meant to say "object" not "objection".
Cc: jdonnelly@chromium.org
jdonnelly@, looks like you already dove into this issue.  It also appears the component you applied isn't being triaged.  Given your past work in locating the relevant code, can you guess at appropriate people to CC on the bug?
Mergedinto: 779414
Status: Duplicate (was: Untriaged)
Looks like a dup of bug 779414.

Sign in to add a comment