As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed.

Thank You!

This is not a Internals > PDF issue, since this happening when using a third party extension not the built-in PDF viewer.. Changing to Platform>Extensions, since it appears to be related to how permissions for extensions work.

[Extensions Triage] Do you see the issue without 'Use Views browser windows instead of Cocoa' on Mac?

Interesting.  This seems like it's mostly WAI - the PDF viewer extension shouldn't be able to see file URLs unless it's enabled in the chrome://extensions page.  But I wouldn't have expected that to be dependent on mac views, or only reproducible on mac and not Linux.  Do we have some magic to handle drag-and-dropping PDF files differently on different platforms?

+Rob, does this seem like a bug or WAI to you?

This bug report does not complain about seeing the URL. The extension being able to observe the file:-URL is expected, the logic is here:
https://github.com/mozilla/pdf.js/blob/7e139776692789fee4b2cedb443715665c5adebe/extensions/chromium/pdfHandler.js#L171-L195

The bug is that clicking on the file chooser causes a new tab to open.
Are there any errors in the JavaScript console?

Hi @ Karandeep,

Retested issue in latest Canary build #70.0.3500.0 on Mac OS and the issue can be reproduced only when 'Use Views browser windows instead of Cocoa' flag is enabled. Unable to reproduce the same issue if flag is disabled. Attaching below the screen-cast of both the (with and without flag) behaviours.

Thank you..!

Deleted: Result_with_cocoa_flag.mov 7.0 MB

	Result_with_cocoa_flag.mov 7.0 MB View Download

Deleted: Result_without_cocoa_flag.mov 6.7 MB

	Result_without_cocoa_flag.mov 6.7 MB View Download

Adding MacViews per #6.

Triage: Sending to tapted@ for initial investigation. This does not affect all webui's, so P2.

it looks like the download shelf (+sdy?) thinks a drag is still in progress after mouse release. So clicking "Choose file" does a repeated "release", triggering a second drop.

The widget isn't releasing capture.

This is meant to happen in views::DragDropClientMac::StartDragAndDrop() (+spqchan)

DownloadItemView overrides View::OnMouseDragged() but doesn't call view::DoDrag -> RunShellDrag() -> StartDragDrop 

Instead it calls DragDownloadItem(), which we still use the Cocoa implementation for rather than the implementation in drag_download_item_views.cc (+ellyjones)

the version in download_item_drag_mac.mm doesn't know it needs to release capture. We can tweak the download shelf to release it manually.

That results in https://chromium-review.googlesource.com/1156192

+tags since this seems fairly fundamental.

This is an M69 merge candidate.

"RBS" as this is P1 and need for M69 per comment #11.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2174d8b05d5e7002579e0dc8ac6f65d1279f222

commit c2174d8b05d5e7002579e0dc8ac6f65d1279f222
Author: Trent Apted <tapted@chromium.org>
Date: Tue Jul 31 21:00:27 2018

MacViewsBrowser: Release capture before starting the native download shelf drag.

Normally drags initiated via views::View::ProcessMouseDragged() complete
in views::View::DoDrag() once exceeding their drag distance threshold.
However, DownloadItemView doesn't set a views::DragController or override
View::GetDragOperations(). Instead, it runs its own drag in an override
of View::OnMouseDragged().

This drag code path isn't aware of the Widget::SetCapture() call done in
Widget::OnMouseEvent(), which needs to be released before an OS-level drag
can take place. Usually this is done by views::DragDropClientMac, which
gets skipped.

To fix, ensure the custom OS-level drag codepath in download_item_drag_mac.mm
releases capture instead.

Bug:  863377 
Change-Id: Ib2f7c80a00dd3b38fe5a98475bddb4e595f3f83c
Reviewed-on: https://chromium-review.googlesource.com/1156192
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579563}
[modify] https://crrev.com/c2174d8b05d5e7002579e0dc8ac6f65d1279f222/chrome/browser/ui/cocoa/download/download_item_drag_mac.mm

Pls request a merge to M69 once CL listed at #13 looks good in canary and safe to merge. Thank you.

Checked 70.0.3510.0 - all good. requesting merge of r579563 to m69

The NextAction date has arrived: 2018-08-02

Update:

Rechecked the above issue on Mac (10.12.6,10.13.1,10.13.6,10.14) using latest canary build 70.0.3510.0 and issue is fixed.
please refer below attached screencast for reference

Thank You...

Deleted: Canary_behaviour.mov 9.6 MB

	Canary_behaviour.mov 9.6 MB View Download

 Issue 689991  has been merged into this issue.

This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving  merge to M69 branch 3497 based on comment #15 and  #17. Please merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6c75fcdc7eaf4ca28e11bbbf862714add11a4b45

commit 6c75fcdc7eaf4ca28e11bbbf862714add11a4b45
Author: Trent Apted <tapted@chromium.org>
Date: Fri Aug 03 00:26:44 2018

[merge-m69] MacViewsBrowser: Release capture before starting the native download shelf drag.

Normally drags initiated via views::View::ProcessMouseDragged() complete
in views::View::DoDrag() once exceeding their drag distance threshold.
However, DownloadItemView doesn't set a views::DragController or override
View::GetDragOperations(). Instead, it runs its own drag in an override
of View::OnMouseDragged().

This drag code path isn't aware of the Widget::SetCapture() call done in
Widget::OnMouseEvent(), which needs to be released before an OS-level drag
can take place. Usually this is done by views::DragDropClientMac, which
gets skipped.

To fix, ensure the custom OS-level drag codepath in download_item_drag_mac.mm
releases capture instead.

TBR=tapted@chromium.org

(cherry picked from commit c2174d8b05d5e7002579e0dc8ac6f65d1279f222)

Bug:  863377 
Change-Id: Ib2f7c80a00dd3b38fe5a98475bddb4e595f3f83c
Reviewed-on: https://chromium-review.googlesource.com/1156192
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#579563}
Reviewed-on: https://chromium-review.googlesource.com/1160830
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#365}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/6c75fcdc7eaf4ca28e11bbbf862714add11a4b45/chrome/browser/ui/cocoa/download/download_item_drag_mac.mm

Update :
------

Tested above issue in latest Beta build #69.0.3497.32 in Mac(10.12.6,10.13.1,10.13.6,10.14) OS and the issue is fixed. Now, 'Choose File' button works as expected in today's Beta build hence adding TE-Verified labels. Kindly review an attached screen-cast for reference.

Thank you..!

Deleted: Beta_build_behaviour.mov 10.7 MB

	Beta_build_behaviour.mov 10.7 MB View Download