Closed Bug 959283 Opened 12 years ago Closed 12 years ago

[B2G][Bluetooth File Transfer] On bluetooth transfer of multiple images opening concurrent recieved pictures through notification bar results in a blank gallery screen

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed)

RESOLVED FIXED
1.3 C2/1.4 S2(17jan)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed

People

(Reporter: bzumwalt, Assigned: johnhu)

References

()

Details

(Keywords: regression, Whiteboard: [fxos:media])

Attachments

(2 files)

Description: When user recieves multiple transferred image files through bluetooth transfer from second device, user is able to get a blank gallery screen. If user opens first received picture using the alert in the notification bar, then while viewing the first image opens a second recieved file from the notification bar the screen displays a titleless blank gallery screen. Repro Steps: 1) Updated Buri to Build ID: 20140113004002 2) Pair two mobile devices using bluetooth 3) Open gallery app on first device and tap selection box icon 4) Select two or more images 5) Press share icon 6) Select Bluetooth Transfer 7) Choose paired recieving device from list 8) On second device accept bluetooth transfer 9) When all files are recieved on second device swipe finger down from top of screen to open notifications bar 10) Select first recieved file 11) With first image open pull down notification bar and select second recieved image file Actual: Opening second recieved bluetooth image while viewing first shows black gallery screen. Expected: User is able to open recieve bluetooth images using notification bar without incident. Environmental Variables Device: Buri v 1.3 Mozilla RIL Build ID: 20140113004002 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/5bb1837de7c0 Gaia: b3fc4f712562ee92b0ed0bd17abc61be9a36a8da Platform Version: 28.0a2 Firmware Version: V1.2-device Notes: Repro frequency: 3/3, 100% See attached: video clip - http://youtu.be/bXklxKAJvuA
Does this reproduce on 1.1 or 1.2?
Component: Gaia::Bluetooth File Transfer → Gaia::Gallery
Keywords: qawanted
.:Does NOT Repro:. Environmental Variables: Device: Buri 1.2 COM BuildID: 20140113004002 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: e672faf1e6a1 Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: v1.2-device.cfg
QA Contact: gbennett
Checking 1.1 tomorrow morning.
(In reply to gbennett from comment #3) > Checking 1.1 tomorrow morning. Actually that's good enough - comment 2 gives us enough evidence that this is a regression.
blocking-b2g: --- → 1.3?
This issue started reproducing on the 11/01/13 1.3 build. - Works - Device: Buri v1.3 MOZ RIL BuildID: 20131031040201 Gaia: 412fd463bcb81f0e8bebf6d32500d0c02712748d Gecko: f0d363d72753 Version: 28.0a1 Firmware Version: V1.2-device.cfg - Broken - Device: Buri v1.3 MOZ RIL BuildID: 20131101040203 Gaia: ccdf357ea150fc7d8b8a4b74c7adf31e7a57e465 Gecko: abe6790a5dd8 Version: 28.0a1 Firmware Version: V1.2-device.cfg
1.3+ for regression
blocking-b2g: 1.3? → 1.3+
Assignee: nobody → johu
The STR of comment 0 can be simplified as the following: 1. using engineering build 2. open UItest -> API -> view photo -> view image and confirm the image is shown 3. send a file through bluetooth 4. open file in the notification bar My first investigation result is: 1. The first created activity (at step 2) gets the message of step 4. But the system app creates another activity on top of it. And the second one doesn't get the message. That's the root cause. 2. At the step 4, there are two duplicated message sent to the first activity and two duplicated activity are created. They may be two different bug. But if we fix the first one, this bug may be fixed.
(In reply to John Hu [:johnhu] from comment #7) > They may be two different bug. But if we fix the first one, this bug may be > fixed. Sorry, I mean the investigation result #2 may be another bug of this one.
John, please note bug 956276 which is a bug on master branch that probably mess up your testing, like your result 2, so you might have to use 1.3 branch so that you won't be confused by that bug.
See Also: → 956276
According to the regression-window, there is a big change on ActivityWindow/ActivityWindowFactory. In the code of [1], ActivityWindowFactory kills all inactive activities with the same source and create a new one even if the last activity which is active is with the same source. [1] https://github.com/mozilla-b2g/gaia/blob/423326d524d3807b3a7ef9cc10f34baf26a34b8c/apps/system/js/activity_window_factory.js#L69-L99
Component: Gaia::Gallery → Gaia::System::Window Mgmt
This patch is for v1.3. I will create another one for master. They are similar but refactored to another function. This patch checks if the manifestURL and url of active _lastActivity are equal to evt.detail's. If they are equal, we don't need to create another activity because the message will be passed to the previous one. If one of them are not equal, we need to create another activity and use _lastActivity as the callee.
Attachment #8360941 - Flags: review?(alive)
PR for master. This is totally the same as v1.3, but it applies to for different function and variable names.
Attachment #8360943 - Flags: review?(alive)
Comment on attachment 8360941 [details] [review] PR for v1.3: not to create another activity when the source of last activity is equal to the request. r+ if you have unit tests for this case.
Attachment #8360941 - Flags: review?(alive) → review+
Comment on attachment 8360943 [details] [review] PR for master: not to create another activity when the source of last activity is equal to the request. r+ if you have unit test
Attachment #8360943 - Flags: review?(alive) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [fxos:media]
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: