Fixed drag & drop for images and files broken (causes screen to go white)

[KevDoy]

Test plan

Conclusive steps to reproduce:

1. Start a fresh instance (on macOS)
2. Load github.com and create an issue
3. Try to drop a file, works.
4. Drag a bookmark or a tab, you pick.
5. Try to drop a file... it should now work (0.13.3 - 0.13.5 it does not work).

Original issue description

• Did you search for similar issues before submitting this one?
  Yes.

• Describe the issue you encountered:
  I am unable to drag any images or files into the browser for websites designed to accept this feature (ie. Hangouts; Google Drive)

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Mac OS X El Capitan

• Brave Version (revision SHA):
  0.13.3 b4cb1f5

• Steps to reproduce:

  1. Open Google Drive.
  2. Drag file from Finder and Drop in Browser Window.
  3. Nothing happens.

• Actual result:
  Nothing.

• Expected result:
  File would begin uploading to, for example, Google Drive

• Will the steps above reproduce in a fresh profile? If not what other info can be added?
  untested

• Is this an issue in the currently released version?
  Yes, just updated

• Can this issue be consistently reproduced?
  Yes

• Extra QA steps:
  1.
  2.
  3.

• Screenshot if needed:

• Any related issues:

[cndouglas]

File uploading here on GitHub is working fine for me with Brave 0.13.4 on macOS 10.12.x.

Have you tried disabling shields? Click the lion icon in the top right and switch Shields to Down.

[KevDoy]

I restarted the browser, without change. Tried it one more time and it did. I'm not sure what the reason was.

[KevDoy]

This continues to happen for me, terminating the Brave task does the trick, but this is definitely new.

[alexwykoff]

While this was not observed in prior builds for me, I have noticed it with a local run of e259d61.

[bsclifton]

I can't repro using master and it works great with 0.13.4... We can retest once a new preview build is cut. It does fail with 0.13.5 preview 1.

Sites which I tried drag and drop using master:

• twitter.com
• GitHub.com
• outlook.com

[bsclifton]

Closing- this appears to work great with 0.13.5 preview 3. Let's re-open if it happens again

I'll keep the milestone just so we can confirm that it works during testing (if it's already in our test plan, we can remove milestone)

[bsclifton]

Re-opening after seeing the issue again in 0.13.5 preview 3 ☹️

I experienced the problem here on GitHub and I believe I have better repro steps:

• I move Brave window out of the way (over to the left or something)
• I click the desktop. Brave does not have focus
• I drop the image file into the text area in GitHub
• The UI shows an animation of the image which was dragged being returned to the desktop
• The entire window goes white and becomes unusable

[NejcZdovc]

@bsclifton I tried these steps, but I couldn't reproduce this error. I experience this kind of error already on 0.13.4, but for now I don't have reproduction steps, it happened 3 or 4 times till now.

[NejcZdovc]

Ok I managed to crash it again (0.13.4). I managed to crash it only after brave was running for a long time, the whole day.

[bsclifton]

I spent about 90 minutes trying to make this happen (in which I ran into issues caused by the Amazon S3 services being down). Regardless of those, I could not get an error to happen. Everything always worked OK. I looked at crash reports on stats.brave.com and didn't see any reports which I believe were mine OR which had information which could be helpful.

Since the steps to repro aren't nailed down, I'm going to push this to 0.13.6. We should definitely keep eyes out for it

[KevDoy]

Here's how it happens for me sometimes.

I have Google Hangouts in a pinned tab.

I open Brave (new session after completely exiting).
Open Hangouts tab. Drag & Drop works. I open a new normal tab, and navigate to Google.com.
I click off of Brave.
Click back on the Pinned Hangouts tab and Drag & Drop stops working on all tabs.

This doesn't always work, and sometimes it just happens after having Brave open for some time.

[bsclifton]

screenshot courtesy of @echosa:

[bbondy]

Reproduces: 0.13.3 (also 0.13.4, 0.13.5, 0.14.0)
Chromium: 56.0.2924.87

Does not reproduce: 0.13.2
Chromium: 54.0.2840.100

Conclusive steps to reproduce:

1. Start a fresh instance
2. Load github.com and create an issue
3. Try to drop a file, works.
4. Drag a bookmark or a tab, you pick.
5. Try to drop a file, does not work.

[bbondy]

Removing all drag and drop handlers completely from our front end still reproduces. So seems like something from the chromium upgrade.

[bbondy]

Verified this does not reproduce on Linux and Windows, it is macOS only.

[bbondy]

This is the commit that introduces the bug:
https://chromium.googlesource.com/chromium/src.git/+/0678253f9e9c12a1cc704721ae6e013860bb909e

In particular isValidDragTarget returns false but only after having dragged a bookmark or tab or some other UI element from the window. I think maybe something like the RenderWidget host gets set to the parent window and not the webview. Still investigating .

Update:
Before dragging the bookmark, when dragging an image onto the webcontents, evaluates this to true (which makes isValidDragTarget return true):
GetRenderViewHostID(webContents_->GetRenderViewHost()) != dragStartViewID_

After dragging the bookmark, when dragging an image onto the webcontents, evaluates this to false (which makes isValidDragTarget return false):

I suspect maybe dragStartViewID_ is not getting rest properly.

[bbondy]

fixed here:
brave/muon@abc37bf

[gregnyc]

Awesome, thanks!

…

On Fri, Mar 17, 2017 at 1:54 PM, Brian R. Bondy ***@***.***> wrote: Closed #7266 <#7266>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7266 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AY9LGZeaKbV4zh4aAvoedHVaijeOysxFks5rmsjlgaJpZM4MCDOQ> .

[bsclifton]

Awesome job, @bbondy! 😄