New issue
Advanced search Search tips

Issue 618213 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

[Windows HID] chrome.hid.disconnect doesn't 'release' the USB device to Windows properly

Reported by i...@solid-optics.eu, Jun 8 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.24 Safari/537.36

Steps to reproduce the problem:
1. Connect to a USB device using a Chrome app with chrome.hid.connect. This needs to be a device that can be used by both Chrome and Windows (a device that is basically used for both a Chrome app and a Windows application (not simultaneously though))
2. After using it with Chrome and we're ready to disconnect this device (release it to Windows) we call chrome.hid.disconnect
3. This results in the device successfully disconnecting from Chrome, which works fine.
4. Afterwards try to access this device using a Windows application
5. Windows cannot find the USB device! (probably because it is still claimed by Chrome in the driver layer perhaps?)
6. Plug the device out and in again, and the Windows application can find the USB device again! 

The problem lies in the fact that a Windows application cannot find this USB device until its 'hard' plugged out and in again. My suspicion is that Chrome does not release the USB device on the driver side, resulting in Windows not being able to detect the device until its 'hard' plugged in again. This is not expected behavior.

What is the expected behavior?
After chrome.hid.disconnect is called, I expected my (custom hardware) USB device to disconnect properly, such that other Windows applications should be able to connect to this USB device, however the HID device can no longer be found by any other application (other than the Chrome app). After chrome.hid.disconnect is called, Chrome does not 'unclaim' the device to windows properly. This prevents other applications from actually being able to find the HID device.

What went wrong?
After chrome.hid.connect and chrome.hid.disconnect is called on a device, no other application will ever be able to access this device until its physically re-plugged into the USB slot.

Did this work before? No 

Chrome version: 52.0.2743.24  Channel: beta
OS Version: 10.0
Flash Version: Shockwave Flash 22.0 r0

Its important to note that we have a Chrome application and a Windows Application which are both able to access and control a single USB device. They are not ment to be used simultaneously, they are used sequentially. When our user is done using the Chrome app, they should be able to connect to the HID device using our Windows application. 

The issue is, if we first connect the USB device with our Windows application, then disconnect it we are perfectly able to connect to Chrome without requiring a replug. But this does not work the other way around! and this vital functionality for us! 

Basically; our Chrome app does some operations, which our Windows application then proceeds on. We do not want our users to disconnect the HID device physically between using these applications. The disconnect functionality should 'release' the USB device. At the moment our Windows application cannot 'find' the USB device until a replug happens.

This functionality is quite important to us, I hope I was clear enough in explaining the issue. if there are any questions please let me know! 

Thanks,

Bas Van Zutphen
Solid Optics
T: EU +31 883 423 776  | US +1 855 678 4271
E: bas@solid-optics.com | it@solid-optics.com | www.solid-optics.com
 
Components: IO>USB Blink>USB

Comment 2 by mspis...@gmail.com, Dec 9 2016

I can confirm this happens to me as well, but only when the chrome.hid session encounters an error.
The error is logged in chrome://device-log and the device becomes unusable in other applications. "cannot open device".
I shutdown Chrome and the device become available again in other (non-Chrome) applications.

Something is not being cleaned up properly when chrome.hid session encounters an error.

This also happens on Chrome 55 and Win 10 (happened on Chrome <55 as well.
Project Member

Comment 3 by bugdroid1@chromium.org, Dec 14 2016

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

commit e62aec48485940cb4e214dd8f6845ebc89f20dee
Author: reillyg <reillyg@chromium.org>
Date: Wed Dec 14 01:11:51 2016

Fix leak of HID transfers and handles on Windows.

This patch reworks the management of PendingHidTransfer objects in the
Windows HID backend so that they are no longer reference counted. It
then adds logic to free all transfers when the device handle is closed
in order to break the circular reference between transfers and the
connection object.

BUG= 618213 

Review-Url: https://codereview.chromium.org/2573683002
Cr-Commit-Position: refs/heads/master@{#438374}

[modify] https://crrev.com/e62aec48485940cb4e214dd8f6845ebc89f20dee/device/hid/hid_connection_win.cc
[modify] https://crrev.com/e62aec48485940cb4e214dd8f6845ebc89f20dee/device/hid/hid_connection_win.h

Owner: reillyg@chromium.org
Status: Fixed (was: Unconfirmed)
Components: -Blink>USB Platform>Extensions>API
Labels: M-56 Merge-Request-56

Comment 6 by dimu@chromium.org, Dec 27 2016

Labels: -Merge-Request-56 Merge-Approved-56 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M56 (branch: 2924)
Project Member

Comment 7 by bugdroid1@chromium.org, Dec 27 2016

Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e1457c475dbea9a5b5fc9305b8975245317985a9

commit e1457c475dbea9a5b5fc9305b8975245317985a9
Author: Reilly Grant <reillyg@chromium.org>
Date: Tue Dec 27 17:42:43 2016

Fix leak of HID transfers and handles on Windows.

This patch reworks the management of PendingHidTransfer objects in the
Windows HID backend so that they are no longer reference counted. It
then adds logic to free all transfers when the device handle is closed
in order to break the circular reference between transfers and the
connection object.

BUG= 618213 

Review-Url: https://codereview.chromium.org/2573683002
Cr-Commit-Position: refs/heads/master@{#438374}
(cherry picked from commit e62aec48485940cb4e214dd8f6845ebc89f20dee)

Review-Url: https://codereview.chromium.org/2605653003 .
Cr-Commit-Position: refs/branch-heads/2924@{#622}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/e1457c475dbea9a5b5fc9305b8975245317985a9/device/hid/hid_connection_win.cc
[modify] https://crrev.com/e1457c475dbea9a5b5fc9305b8975245317985a9/device/hid/hid_connection_win.h

Sign in to add a comment