Closed Bug 1015006 Opened 7 years ago Closed 7 years ago

[MADAI] When start Video App or Music App, a PC connected warning is displayed though unplugged PC.

Categories

(Core :: DOM: Device Interfaces, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
2.0 S3 (6june)
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: hyeyoung1024.kim, Assigned: dhylands)

Details

(Keywords: common-issue+, Whiteboard: ums,)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce:

* Precondition :
1. Enable USB storage (from settings)
2. Enable Share using USB (settings -> Media storage)
3. Should have some videos in SD card

* Steps to reproduce:
1. Open video application and Play a video
2. Plug-in the USB cable
3. When the "Video can not be watched while plugged in / Unplug the phone to watch videos" pop-up
is shown immediately remove the USB cable






Actual results:

The pop-up is still shown even after removing the USB cable.
After then, Even if I re-start Video app, The pop-up isn't disappeared.

this is easily reproduced.

Please refer attached the video "Video_App_Reproduced.mp4"

* reproduced video link :
http://blogattach.naver.com/58cd44f4e6b5bc604eaacbffc02452238ad128c476/20140520_256_blogfile/1024hyeyoung_1400574088347_8fgKV9_mp4/Video_App_Reproduced%2801%29.mp4?type=attachment


Expected results:

The warning pop-up should be disappeared when usb cable is removed.
(Warning pop-up : "Video can not be watched while plugged in / Unplug the phone to watch videos")
also, I attached the log.
====================
(1) main_ok.log : 
http://blogattach.naver.com/dc49c073613f38e4ca2e4f7b44a0d6a70e55ac4f95/20140520_13_blogfile/1024hyeyoung_1400573686610_2uEqbo_log/main_ok.log?type=attachment

(2) main_NG.log:
http://blogattach.naver.com/46d35aeaffa3a27e50b4d5e1de3a4c3d94cf36daed/20140520_21_blogfile/1024hyeyoung_1400573689687_44TcK9_log/main_NG.log?type=attachment
==================

If you check the log I attached, you can find that The state was not changed to "unmount" when connecting usb cable.

 
* Success Case.
==========================================
<main_ok.log>

1890	AutoMounter:		 UsbCable switch device: 1 state: plugged
1891	AutoMounter:		 Calling UpdateState due to USBCableEvent
1892	AutoMounter:		 UpdateState: umsAvail:1 umsEnabled:1 mode:1 usbCablePluggedIn:1 tryToShare:1
1893	AutoMounter:		 UpdateState: Volume sdcard1 is Mounted and inserted @ /storage/sdcard1 gen 1 locked 0 sharing y
1894	VolumeManager:		 Volume sdcard1: IsSharing set to 1 state Mounted

1909	AutoMounter:		 The following files are open under /storage/sdcard1
1910	AutoMounter:		   PID: 1429 file: /storage/sdcard1/LG서초/V2010_0313_0413.3gp app: Video comm: Video exe: /system/b2g/plugin-container
1911	AutoMounter:		 UpdateState: Mounted volume sdcard1 has open files, not sharing or formatting

1955	OMXCodec:		 [OMX.qcom.video.decoder.mpeg4] pause mState=4
1956	OMXCodec:		 [OMX.qcom.video.decoder.mpeg4] onStateChange 4
1957	OMXCodec:		 [OMX.qcom.video.decoder.mpeg4] Now paused.



2080	AutoMounter:		 UpdateState: umsAvail:1 umsEnabled:1 mode:1 usbCablePluggedIn:1 tryToShare:1
2081	AutoMounter:		 UpdateState: Volume sdcard1 is Mounted and inserted @ /storage/sdcard1 gen 1 locked 0 sharing y
2082	AutoMounter:		 UpdateState: Unmounting sdcard1
2083	VolumeManager:		 Volume sdcard1: changing state from Mounted to Unmounting (2 observers)
==========================================



* Issue Case.
==========================
<main_NG.log>

67380	AutoMounter:		 UsbCable switch device: 1 state: plugged
67381	AutoMounter:		 Calling UpdateState due to USBCableEvent
67382	AutoMounter:		 UpdateState: umsAvail:1 umsEnabled:1 mode:1 usbCablePluggedIn:1 tryToShare:1
67383	AutoMounter:		 UpdateState: Volume sdcard1 is Mounted and inserted @ /storage/sdcard1 gen 6 locked 0 sharing y
67384	VolumeManager:		 Volume sdcard1: IsSharing set to 1 state Mounted
67385	AutoMounter:		 Calling UpdateState due to VolumeEventStateObserver

67406	AutoMounter:		 The following files are open under /storage/sdcard1
67407	AutoMounter:		   PID: 1378 file: /storage/sdcard1/LG서초/V2010_0208_0740.3gp app: Video comm: Video exe: /system/b2g/plugin-container
67413	AutoMounter:		 UpdateState: Mounted volume sdcard1 has open files, not sharing or formatting


67478	OMXCodec:		 [OMX.qcom.video.decoder.mpeg4] pause mState=4
67479	OMXCodec:		 [OMX.qcom.video.decoder.mpeg4] onStateChange 4
67480	OMXCodec:		 [OMX.qcom.video.decoder.mpeg4] Now paused.


******* it did not do "unmount volume", Even though usb cable was plugged.


67597	AutoMounter:		 UsbCable switch device: 1 state: unplugged
67598	AutoMounter:		 Calling UpdateState due to USBCableEvent
67599	AutoMounter:		 UpdateState: umsAvail:1 umsEnabled:1 mode:1 usbCablePluggedIn:0 tryToShare:0
67600	AutoMounter:		 UpdateState: Volume sdcard1 is Mounted and inserted @ /storage/sdcard1 gen 6 locked 0 sharing y

******* So, Volume sdcard1's previous state is still left " Mounted" at this time.
 
67601	AutoMounterSetting:		 Changing status from FilesOpen to Enabled

================================






When I checked "AutoMounter.cpp", (http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/AutoMounter.cpp)
There is nothing to do in this conditions "tryToShare is 0, volState : STATE_MOUNTED".

=======================================================================
void
AutoMounter::UpdateState()
{

....
 if ((tryToShare && vol->IsSharingEnabled()) ||
        vol->IsFormatRequested() ||
        vol->IsUnmountRequested()) {

....
}else{
 // We're going to try and unshare and remount the volumes
      switch (volState) {
        case nsIVolume::STATE_SHARED: {
          // Volume is shared. We can go ahead and unshare.
          LOG("UpdateState: Unsharing %s", vol->NameStr());
          vol->StartUnshare(mResponseCallback);
          return; // UpdateState will be called again when the Unshare command completes
        }
        case nsIVolume::STATE_IDLE: {
          if (!vol->IsUnmountRequested()) {
            // Volume is unmounted and mount-requested, try to mount.

            LOG("UpdateState: Mounting %s", vol->NameStr());
            vol->StartMount(mResponseCallback);
          }
          return; // UpdateState will be called again when Mount command completes
        }
        default: {
          // Not in a state that we can do anything about.
          break;

}
}
}
}

===========================================================================

Please check this.

Thank you.
Hyeyoung, Kim
blocking-b2g: --- → 1.4?
status-b2g-v1.4: --- → ?
Keywords: common-issue+
OS: All → Gonk (Firefox OS)
Priority: -- → P2
Hardware: All → ARM
Whiteboard: ums,
Flags: needinfo?(dhylands)
(In reply to hyeyoung1024.kim from comment #1)

> ******* it did not do "unmount volume", Even though usb cable was plugged.

That is correct. As long as there are open files, it won't unmount the volume.

 
> ******* So, Volume sdcard1's previous state is still left " Mounted" at this
> time.
>  
> 67601	AutoMounterSetting:		 Changing status from FilesOpen to Enabled

I think that the issue is this:

http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/AutoMounter.cpp?from=AutoMounter.cpp#490
we mark the volume as sharing "early" (i.e. before we check for open files). This causes notifications to be sent to the media apps and they then detect this, are supposed to close their open files, and then the sharing option will commence.

If the USB cable is unplugged in this state, then the volume remains mounted, but SetIsSharing is never set to false, so the media apps still think that the volume is trying to be shared (and this is why the dialog stays up).

So the AutoMounter needs some additional logic to detect "state == Mounted" and "USB Cable unplugged" in order to call SetIsSharing(false), which will in turn cause the state reported to the media app to transition from "sharing" back to "available".

Normally the volume's mIsSharing gets set to false when the volume actually transitions state:
http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/Volume.cpp#195

but in the scenario where the USB cable is unplugged while mIsSharing is set to true, there is no actual transition of the volume state (it was mounted before mIsSharing was set to true, and its still mounted when the USB cable is unplugged).

I'll fix this.
Assignee: nobody → dhylands
Flags: needinfo?(dhylands)
I was able to reproduce on my flame.

The secret to reproducing is that you need to pull the cable "as soon as" the dialog occurs.

You can recover by plugging the USB cable back in for 10-15 seconds and then unplug. This will cause the dialog to disappear (which confirms my analysis in comment 2 about what's going on).
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
With this patch, we'll now detect that mIsSharing is true and if we detect that the USB cable gets unplugged then we'll force SetIsSharing back to false. 

Normally mIsSharing will automatically get set to false when the volume transitions back to the mounted state, but in the scenario described in the bug, the volume never actually leaves the mounted state, so it never transitions back to the mounted state, and this means that mIsSharing doesn't get cleared.
Attachment #8428197 - Flags: review?(kyle)
Dear, Dave Hylands.

I tested it with your patch.

this issue wasn't reproduced.

It looks like it's fixed.

Thank you for investigating.


After Review, It will be merged on B2G v1.4, Is it right?


Thanks,
Hyeyoung, Kim
Flags: needinfo?(dhylands)
Currently, this bug is marked as 1.4?, which means that it has been nominated as a blocker for 1.4, but hasn't yet been approved to be included in 1.4.

If and when it becomes approved as a blocker for 1.4, then it will be changed to 1.4+ and typically within a day or so of that the patch will be uplifted to 1.4. If it doesn't get approved as a blocker, you can still request approval for landing on 1.4.
Flags: needinfo?(dhylands)
blocking-b2g: 1.4? → 1.4+
Target Milestone: --- → 2.0 S3 (6june)
Component: General → DOM
Product: Firefox OS → Core
Component: DOM → DOM: Device Interfaces
Attachment #8428197 - Flags: review?(kyle) → review+
https://hg.mozilla.org/mozilla-central/rev/dc6369dfd697
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Group: kddi-confidential
Why was this marked confidential? It shouldn't have been.

This was a reproduced and fixed problem on the flame.
Group: kddi-confidential
You need to log in before you can comment on or make changes to this bug.