Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

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

Closed
KevDoy opened this issue Feb 15, 2017 · 27 comments
Closed

Comments

@KevDoy
Copy link

KevDoy commented Feb 15, 2017

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
Copy link

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
Copy link
Author

KevDoy commented Feb 16, 2017

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

@KevDoy
Copy link
Author

KevDoy commented Feb 16, 2017

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

@cndouglas cndouglas reopened this Feb 17, 2017
@cndouglas cndouglas removed the invalid label Feb 17, 2017
@alexwykoff alexwykoff added this to the 0.13.6 milestone Feb 20, 2017
@alexwykoff
Copy link
Contributor

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

@bbondy bbondy modified the milestones: 0.13.5, 0.13.6 Feb 20, 2017
@bsclifton bsclifton self-assigned this Feb 25, 2017
@bsclifton
Copy link
Member

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 bsclifton removed their assignment Feb 25, 2017
@bsclifton
Copy link
Member

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
Copy link
Member

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

@bsclifton bsclifton reopened this Feb 28, 2017
@NejcZdovc
Copy link
Contributor

@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
Copy link
Contributor

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 bsclifton self-assigned this Feb 28, 2017
@bsclifton
Copy link
Member

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

@bsclifton bsclifton modified the milestones: 0.13.6, 0.13.5 Feb 28, 2017
@bsclifton bsclifton removed their assignment Feb 28, 2017
@KevDoy
Copy link
Author

KevDoy commented Mar 1, 2017

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 bsclifton changed the title Drag & Drop for Images and Files Broken // 0.13.3 macOS Drag & Drop for Images and Files Broken (causes screen to go white) Mar 1, 2017
@bsclifton
Copy link
Member

screenshot courtesy of @echosa:
screen shot 2017-03-01 at 11 30 47 am

@bbondy
Copy link
Member

bbondy commented Mar 17, 2017

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
Copy link
Member

bbondy commented Mar 17, 2017

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

@bbondy
Copy link
Member

bbondy commented Mar 17, 2017

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

@bbondy
Copy link
Member

bbondy commented Mar 17, 2017

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 added a commit to brave/muon that referenced this issue Mar 17, 2017
...and sometimes leads to a crash.

Auditors: @bridiver

Fix brave/browser-laptop#7266

Browser process's content class WebContentsView has a different implementation on macOS vs Linux and Windows.  When dragging starts, a start view ID gets set on both implementations, but it wasn't getting cleared on the macOS implementation. So dragging a bookmark, tab or other chrome element in our UI would then cause future drags in a webview from an external source to stop working and to sometimes crash (whitescreen the whole window).  Seems like a chromium bug to me but I think they aren't affected by it.
@bbondy
Copy link
Member

bbondy commented Mar 17, 2017

fixed here:
brave/muon@abc37bf

@bbondy bbondy closed this as completed Mar 17, 2017
@gregnyc
Copy link

gregnyc commented Mar 17, 2017 via email

@luixxiul luixxiul added QA/test-plan-specified release-notes/include and removed needs-investigation A bug not 100% confirmed/fixed that needs QA to better audit. labels Mar 17, 2017
@bsclifton
Copy link
Member

Awesome job, @bbondy! 😄

bridiver pushed a commit to brave/muon that referenced this issue Mar 23, 2017
...and sometimes leads to a crash.

Auditors: @bridiver

Fix brave/browser-laptop#7266

Browser process's content class WebContentsView has a different implementation on macOS vs Linux and Windows.  When dragging starts, a start view ID gets set on both implementations, but it wasn't getting cleared on the macOS implementation. So dragging a bookmark, tab or other chrome element in our UI would then cause future drags in a webview from an external source to stop working and to sometimes crash (whitescreen the whole window).  Seems like a chromium bug to me but I think they aren't affected by it.
@alexwykoff alexwykoff changed the title Drag & Drop for Images and Files Broken (causes screen to go white) Fixed drag & drop for images and files broken (causes screen to go white) Mar 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.