Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Drag-and-drop files not working on Windows Aura
Reported by bishopje...@gmail.com, Jan 9 2014 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Safari/537.36

Steps to reproduce the problem:
1. Go to http://html5-demos.appspot.com/static/dnd/all_types_of_import.html
2. Drag files (not directories) onto the drop area

What is the expected behavior?
The file should be interpreted and read correctly.
event.dataTransfer.items should read all files and be of length equal to the number of files. Also, event.dataTransfer.files should read all files and be of length equal to the number of files.

What went wrong?
event.dataTransfer.items reads an additional DataTransferItem as a string (the url of the file if available), meaning event.dataTransfer.items.length == (numFiles + 1) and event.dataTransfer.files.length == (numFiles).
This is changed functionality from Chrome Version 31.

Did this work before? Yes 31.0.1650.63 m

Chrome version: 32.0.1700.72  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 12.0 r0
 
Additional Details for expected behavior: should display all dropped files.
Additional Details for what went wrong: only displays n-1 dropped files (due to javascript error for when checking files[i].type as it is out of bounds).
Cc: cpu@chromium.org jam...@chromium.org komoroske@chromium.org
Labels: M-32
Sounds like Blink drag and drop functionality may be messed up in Aura.

Alex or James, do you know who might know about drag and drop? I do'nt know the right Blink owner.
Cc: wiltzius@chromium.org
Is this affecting production web sites? Anyone please block release blocking if this should stop the impending M32 push.
Cc: ojan@chromium.org
Labels: Cr-Blink-
Elliott tells me that if this is Aura-specific it's likely a problem with what the embedder is passing to Blink, and that the Blink side of things doesn't have a clear owner or maintainer.

+ a few folks who might know more.
Comment 5 by royans@chromium.org, Jan 10 2014
Cc: lafo...@chromium.org apps-tses-bugs@chromium.org eso-chrome@chromium.org
 Issue 333320  has been merged into this issue.
Comment 6 by royans@chromium.org, Jan 10 2014
Labels: -Pri-2 Pri-1 ReleaseBlock-Stable Hotlist-Enteprrise
Summary: Drag-and-drop files problematic ( was working in 31, broke in 32 ) (was: Drag-and-drop files problematic)
Updating labels to reflect that this may be a big issue. Not a P0, but should be a P1 for sure.
Comment 7 by kareng@google.com, Jan 10 2014
Labels: Needs-Bisect
Owner: wiltzius@chromium.org
Status: Assigned
tom's working on getting an owner for this. I am assuming it's there from aura but might be good to get a bisect.
Cc: scot...@gmail.com
Labels: -Cr-Blink- Cr-Blink Cr-Internals-Aura
Owner: scottmg@chromium.org
Scottmg can you dig in to the embedder side? jamesr@ may be able to help if you need some info about Blink.

I suspect this was always broken in Aura and we just never noticed.
Comment 9 by jam...@chromium.org, Jan 10 2014
Cc: e...@chromium.org
Can we get a bisect?  Is this aura or something that broke at the same time?
Cc: vivianz@chromium.org
I think its probably just Aura, but we can try a bisect. Vivian can you have QA give it a shot? 
Cc: dcheng@chromium.org
Comment 13 by e...@chromium.org, Jan 10 2014
This sounds like a Windows version of the Linux  Issue 318796  (of which the fix https://codereview.chromium.org/133053003/ is in the CQ right now).
Labels: -Needs-Bisect
Status: Started
Don't bother with the bisect, I'll look now.
I'm not sure  issue 333320  is the same thing.

- Dragging to Dropbox worked fine on 34.0.1777.0 for me.

- Comment #0 i.e. http://html5-demos.appspot.com/static/dnd/all_types_of_import.html doesn't work, I get "Cannot read property 'type' of undefined onDrop".

- Dragging an image from gmail to the desktop ( issue 333320 ) doesn't download the file, but instead creates an shortcut.


I'm happy to undup the bugs. 333320 is specifically about drag from gmail to desktop not working. I've tested with multiple versions and I'm confident 32 started causing this. We duped to this bug because its close, but its possible they are not identical.
Sometimes (most times?) we don't even seem to accept drag from explorer at HEAD. :( So I guess I'll look into that first.
I have no idea about #17, I can't get local builds to accept drag from explorer. Maybe needs to be branding=Chrome? Or doesn't work in shared_library? Both seem pretty unlikely, but I always get the NO cursor.

Since I can repro the dragging-from-gmail issue, I'll do that part first. There's actually two different behaviours, depending on where you drag from. From some parts of the attachment preview you get a useless URL, and from other parts you get an image download, but its of the thumbnail, not the actual image. Hmm.
I confirm that the gmail drag is aura vs. not-aura, rather than some unrelated coincident change.
For dragging out (the gmail case), we never set a CF_HDROP when going through the aura path. This used to be done here, I believe: https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/web_contents/web_contents_drag_win.cc&l=224

One "scottmg" allegedly tried to change code related to this here http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_view_aura.cc?r1=221839&r2=221840& . I asked him about it but he had no memory of this particular incident. That change turns out to only handle when the drag object is actually the image (so, e.g. dragging a plain <img> link from wikipedia).

I'm hopeful that porting over something like PrepareDragForDownload will fix this, but it's probably not going to make the current stable push.
There's a CL here https://codereview.chromium.org/135393002 that works (for dragging out of gmail,  bug 333320 ), but asserts in debug because it has to do file operations and is naturally on the UI thread.

The native windows path (WebContentsDragWin::StartDragging) creates a new thread on every drag and dispatches to it, which is why this doesn't assert. I'm scared to do that, especially for merging to 32. It might be safer to just ScopedAllowIO since who knows what other wacky COM/OLE/DDE/ProgMan stuff is going on during drags out of chrome anyway.
Yeah, I'm not adding a new thread at this point: https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/web_contents/web_contents_drag_win.cc&l=80 . We do AttachThreadInput to the UI thread anyway so I'm not sure we're getting much in the way of jank-prevention with that background thread.
Project Member Comment 23 by bugdroid1@chromium.org, Jan 11 2014
------------------------------------------------------------------------
r244355 | scottmg@chromium.org | 2014-01-11T17:49:55.547682Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_view_aura.cc?r1=244355&r2=244354&pathrev=244355

Add CF_HDROP path for dragging on Win Aura

This ports the PrepareDragForDownload path over from the native windows
code path. This makes dragging files to explorer from, for example, gmail
save the content of the file, rather than a link, or the thumbnail
image.

(This needs to be merged to 32, so attempted to keep it semi-localized.)

BUG= 332579 , 333320 
R=ben@chromium.org

Review URL: https://codereview.chromium.org/135393002
------------------------------------------------------------------------
Labels: Merge-Requested
(after it's been through Canary)
Labels: M-33
We should merge to M33 at minimum, and ideally would merge for M32 but not if it seems risky and not for stable 1, only for stable 2. So need Laforge's OK for 33 and Karen's for 32.
Project Member Comment 26 by bugdroid1@chromium.org, Jan 13 2014
------------------------------------------------------------------------
r244538 | dcheng@chromium.org | 2014-01-13T18:22:22.703632Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_win.h?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/toolbar/home_button.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_unittest.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data.h?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/bookmarks/bookmark_node_data_views.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_aurax11_unittest.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_win_unittest.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_aurax11.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_view_aura.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_aurax11.h?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/frame/browser_root_view.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_aura.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_aura.h?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/bookmarks/bookmark_node_data_unittest.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/tabs/tab_strip.cc?r1=244538&r2=244537&pathrev=244538
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/base/dragdrop/os_exchange_data_provider_win.cc?r1=244538&r2=244537&pathrev=244538

Don't populate URL data in WebDropData when dragging files.

This is considered a potential security issue as well, since it leaks
filesystem paths.

BUG= 332579 

Review URL: https://codereview.chromium.org/135633002
------------------------------------------------------------------------
Comment 27 by laforge@google.com, Jan 13 2014
Labels: -Merge-Requested Merge-Approved
33 only? Both patches?
Comment 29 by laforge@google.com, Jan 13 2014
33 only, what are your thoughts on the second patch?
I guess we should probably let it run through a canary first. WDYT dcheng? I'll merge 244355 now.
Yes, letting it bake in canary seems prudent.
Project Member Comment 32 by bugdroid1@chromium.org, Jan 13 2014
Labels: -Merge-Approved merge-merged-1750
------------------------------------------------------------------------
r244562 | scottmg@chromium.org | 2014-01-13T19:51:42.996618Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/content/browser/web_contents/web_contents_view_aura.cc?r1=244562&r2=244561&pathrev=244562

Merge 244355 "Add CF_HDROP path for dragging on Win Aura"

> Add CF_HDROP path for dragging on Win Aura
> 
> This ports the PrepareDragForDownload path over from the native windows
> code path. This makes dragging files to explorer from, for example, gmail
> save the content of the file, rather than a link, or the thumbnail
> image.
> 
> (This needs to be merged to 32, so attempted to keep it semi-localized.)
> 
> BUG= 332579 , 333320 
> R=ben@chromium.org
> 
> Review URL: https://codereview.chromium.org/135393002

TBR=laforge@chromium.org

Review URL: https://codereview.chromium.org/137253002
------------------------------------------------------------------------
That issue affects all production environment using the Moxiecode Plupload module (drag-drop sample here does not work in chrome32 http://www.plupload.com/examples/).
Do you have a non-minified version to test against?
Labels: Merge-Requested
We should probably merge back the second patch as well. It breaks dragging in files to navigate, and is considered an information disclosure bug as well.
Comment 36 by laforge@google.com, Jan 16 2014
Labels: -Merge-Requested Merge-Approved
Approved to merge to m33 (1750).  Please get a second approval from Karen to merge to M32 (1700).
Project Member Comment 37 by bugdroid1@chromium.org, Jan 16 2014
Labels: -Merge-Approved
------------------------------------------------------------------------
r245053 | dcheng@chromium.org | 2014-01-16T01:47:55.148673Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_provider_aurax11_unittest.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_provider_aurax11.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/content/browser/web_contents/web_contents_view_aura.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/browser/ui/views/frame/browser_root_view.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_provider_aura.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_provider_aura.h?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/browser/bookmarks/bookmark_node_data_unittest.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/browser/ui/views/tabs/tab_strip.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_provider_win.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_provider_win.h?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/browser/ui/views/toolbar/home_button.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data_unittest.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/base/dragdrop/os_exchange_data.h?r1=245053&r2=245052&pathrev=245053
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/browser/bookmarks/bookmark_node_data_views.cc?r1=245053&r2=245052&pathrev=245053

Merge 244538 "Don't populate URL data in WebDropData when draggi..."

> Don't populate URL data in WebDropData when dragging files.
> 
> This is considered a potential security issue as well, since it leaks
> filesystem paths.
> 
> BUG= 332579 
> 
> Review URL: https://codereview.chromium.org/135633002

TBR=dcheng@chromium.org

Review URL: https://codereview.chromium.org/137783015
------------------------------------------------------------------------
Comment 38 Deleted
Comment 39 by Deleted ...@, Jan 16 2014
I don't know if this is related, but the text/uri-list data type seems to get blasted in my code now (in 32 and in 34) -- it simply isn't present for getData on the drop event. All other data types remain.
#39, probably. Do you have an example?
Comment 41 by Deleted ...@, Jan 16 2014
Apologies, I figured it out: Chrome (but not Safari or Firefox?) validates the URL of text/uri-list, and if invalid, nukes it before the drop event.
Cc: kinuko@chromium.org
I haven't had a lot of time to investigate #33, but it looks like the success callback for FileEntry.file() is not getting invoked on Windows...
Cc: sentaro@chromium.org
Comment 44 by ojan@chromium.org, Jan 17 2014
Cc: -ojan@chromium.org
Comment 45 by kareng@google.com, Jan 17 2014
Labels: Merge-Approved
scott i think for m32 we want r244562 right?
Project Member Comment 46 by bugdroid1@chromium.org, Jan 18 2014
Labels: -Merge-Approved merge-merged-1700
------------------------------------------------------------------------
r245662 | scottmg@chromium.org | 2014-01-17T23:56:22.208016Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/content/browser/web_contents/web_contents_view_aura.cc?r1=245662&r2=245661&pathrev=245662

Merge 244355 "Add CF_HDROP path for dragging on Win Aura"

> Add CF_HDROP path for dragging on Win Aura
> 
> This ports the PrepareDragForDownload path over from the native windows
> code path. This makes dragging files to explorer from, for example, gmail
> save the content of the file, rather than a link, or the thumbnail
> image.
> 
> (This needs to be merged to 32, so attempted to keep it semi-localized.)
> 
> BUG= 332579 , 333320 
> R=ben@chromium.org
> 
> Review URL: https://codereview.chromium.org/135393002

TBR=karen@chromium.org

Review URL: https://codereview.chromium.org/142003007
------------------------------------------------------------------------
Labels: -Type-Bug Type-Bug-Security Security_Impact-Stable
I'm going to add some security flags so this can be triaged appropriately for leaking filesystem paths to web content... I think it's probably fine not to merge r244538 to M32, but I'd like to confirm.
Project Member Comment 48 by clusterf...@chromium.org, Jan 18 2014
Labels: Missing_Severity-4
Project Member Comment 49 by bugdroid1@chromium.org, Jan 18 2014
------------------------------------------------------------------------
r245791 | laforge@chromium.org | 2014-01-18T20:29:47.051440Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/content/browser/web_contents/web_contents_view_aura.cc?r1=245791&r2=245790&pathrev=245791

Revert 245662 "Merge 244355 "Add CF_HDROP path for dragging on W..."

> Merge 244355 "Add CF_HDROP path for dragging on Win Aura"
> 
> > Add CF_HDROP path for dragging on Win Aura
> > 
> > This ports the PrepareDragForDownload path over from the native windows
> > code path. This makes dragging files to explorer from, for example, gmail
> > save the content of the file, rather than a link, or the thumbnail
> > image.
> > 
> > (This needs to be merged to 32, so attempted to keep it semi-localized.)
> > 
> > BUG= 332579 , 333320 
> > R=ben@chromium.org
> > 
> > Review URL: https://codereview.chromium.org/135393002
> 
> TBR=karen@chromium.org
> 
> Review URL: https://codereview.chromium.org/142003007

TBR=scottmg@chromium.org

Review URL: https://codereview.chromium.org/142423002
------------------------------------------------------------------------
Project Member Comment 50 by bugdroid1@chromium.org, Jan 19 2014
------------------------------------------------------------------------
r245809 | scottmg@chromium.org | 2014-01-19T04:36:10.094824Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/content/browser/web_contents/web_contents_view_aura.cc?r1=245809&r2=245808&pathrev=245809

Merge 244355 "Add CF_HDROP path for dragging on Win Aura"

With attempted compile fix for files moved since branch.

> Add CF_HDROP path for dragging on Win Aura
> 
> This ports the PrepareDragForDownload path over from the native windows
> code path. This makes dragging files to explorer from, for example, gmail
> save the content of the file, rather than a link, or the thumbnail
> image.
> 
> (This needs to be merged to 32, so attempted to keep it semi-localized.)
> 
> BUG= 332579 , 333320 
> R=ben@chromium.org
> 
> Review URL: https://codereview.chromium.org/135393002

TBR=karen@chromium.org

Review URL: https://codereview.chromium.org/137783028
------------------------------------------------------------------------
Project Member Comment 51 by clusterf...@chromium.org, Jan 19 2014
Labels: -Missing_Severity-4 Missing_Severity-5
Comment 52 by kenrb@chromium.org, Jan 20 2014
 Issue 335971  has been merged into this issue.
Comment 53 by kenrb@chromium.org, Jan 20 2014
Labels: Security_Severity-Low
Project Member Comment 54 by clusterf...@chromium.org, Jan 20 2014
Labels: Security_Impact-Beta
Comment 55 by kareng@google.com, Jan 23 2014
Status: Fixed
Cc: srsridhar@chromium.org
Labels: TE-Verified-M33 TE-Verified-M34 Needs-Feedback
Tested the issue on Windows 7/8 OS - chrome version 33.0.1750.54 (Official Build 247046)  and 34.0.1807.0 (Official Build 247146) canary. Able to drag and drop files is working fine.

But issue is still existing on M32 32.0.1700.102 (Official Build 246481) m. Please confirm us if the fix is merged to M32.
Today Chrome 'stable' updated to version 32.0.1700.102 m in my computer and the drag & drop issue is now solved.
Today Chrome 'stable' updated to version 32.0.1700.102 m in my computer (Win7) and the drag & drop issue is still broken. :(

Tested at: http://html5-demos.appspot.com/static/dnd/all_types_of_import.html
"Uncaught TypeError: Cannot read property 'type' of undefined" "all_types_of_import.html:335" in the console
updated to version 32.0.1700.102, on Mac OS X 10.9.1  --> the drag & drop issue is still broken

Reproduce in Gmail and with http://html5-demos.appspot.com/static/dnd/all_types_of_import.html
Labels: Release-0-M33
32.0.1700.102, on Linux Mint 15 --> issue still not resolved. 
Comment 62 by dharani@google.com, Feb 19 2014
Labels: CVE-2013-6660
Comment 63 by Deleted ...@, Feb 27 2014
I just noticed today, 02/27/14 that Chrome now prompts for the Windows login ID and psswrd when viewing the passwords stored in Chrome. 

Is this a feature, or have I been hacked?
@bpilkey - I'm not sure what your question has to do with this specific bug. Questions like this are better directed to security@chromium.org.  It is a feature, though.
I see this issue has been closed, is there a new ticket on this as I am still experiencing drag & drop issue using Version 33.0.1750.154 m
Please file a new bug at http://crbug.com/new
Comment 67 by Deleted ...@, Mar 20 2014
XUbuntu 13.04 / Chrome 35.0.1883.0 dev aura 
The issue still here, dnd file doesn't work
Please file a new bug at http://crbug.com/new. This one was specific to Windows. Thanks.
Still broken for me on Chrome 33.0.1750.152 on Mac OS X 10.9.2. Using http://fineuploader.com/ library.
Summary: Drag-and-drop files not working on Windows Aura (was: Drag-and-drop files problematic ( was working in 31, broke in 32 ))
Like I've stated, please file a new bug for other issues. This specific bug is about Windows Aura file drag and drop, and I've updated the title to reflect that. It gets quite complicated to keep tracking several different bugs on several different platforms in this one issue. Thank you.
Project Member Comment 71 by clusterf...@chromium.org, Feb 2 2016
Labels: -Security_Impact-Beta
Project Member Comment 72 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 73 by sheriffbot@chromium.org, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 74 by sheriffbot@chromium.org, Oct 2 2016
Labels: Restrict-View-SecurityNotify
Labels: allpublic
Project Member Comment 76 by sheriffbot@chromium.org, Oct 3 2016
Labels: -Restrict-View-SecurityNotify
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment