[FFOS2.0][WOODDUCK][Lock screen]Lock screen is freezed CONTACT INFO (Name,Phone number): Tubinjian 0752 8228616 DEFECT DESCRIPTION: 1.Phone can't be unlocked in Lockscreen 2.but the Power key and volume key are work. 3.if get an incoming call when Lockscreen is freezed,the incoming call can be displayed but can't be answered. REPRODUCING PROCEDURES: EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:

1. 锁屏界面的pointer-events状态错误（为“none”），导致不接收任何触碰事件； 2. 锁屏界面上覆盖了一层透明的层，它阻碍了锁屏界面接收触碰事件； 3. 底层（gecko甚至是硬件平台）的触碰消息传递发生紊乱 （据之前分析，开发这边已经确认有这样的情况：诸如原本应该是“松开消息”却传递了一个“按下消息”上来）

Will check internally for proper resource to provide suggestion, once TPE office start to work. Now there is big typhoon hitting Taiwan so office is closed on Monday and Tuesday morning. (typhoon holiday) keeps my ni.

Now TPE office is closed all day Tuesday due to typhoon, mail sent internally to see if there is people able to check today. keeps my ni.

hi wesly, do you know if other OEM met the same issue?

Hi DengWei: After check w/ some people internally: A. In our memory there is no OEM reported this before. B. For the 3 hypothesis you mentioned in comment#1: (1)&(2) looks the same to us, and back to long time ago there should be some issue related and fixed for a case "no touch response if double press power key to suspend & resume the phone, right after enabling screen lock". Unfortunately we are not able to find corresponding bugzilla id now, but this could be a hint for your reproduction. for (3) there seems another issue related & fixed for case "no touch response after power on" but not sure if there's a bugzilla id for it, and this could be another way you can try. However w/o log we are hard to proceed so can only provide some "guess" suggestion at this moment. Thanks for the understanding. (In reply to sync-1 from comment #1) > 1. 锁屏界面的pointer-events状态错误（为“none”），导致不接收任何触碰事件； > 2. 锁屏界面上覆盖了一层透明的层，它阻碍了锁屏界面接收触碰事件； > 3. 底层（gecko甚至是硬件平台）的触碰消息传递发生紊乱 > （据之前分析，开发这边已经确认有这样的情况：诸如原本应该是“松开消息”却传递了一个“按下消息”上来）

settings-->enable Lockscreen-->press power key--->device freeze in settings interface. hi Wesly, as you said the issue has been reproduced in Woodduck. do you have corresponding patch send to us to fix this issue?

Hi DengWei, please help attache log for us to check. @Greg, once there is log, would you help check first? Thank you!

Binjian, please upload the logs to here.

upload logs.

"no touch response if double press power key to suspend & resume the phone, right after enabling screen lock." as you reported, this issue still exists on our platform. We all reproduced yesterday evening by exactly following the reproduce steps you told us. Could you do us a favour by: 1. Reproduce the issue by you hand 2. Provide the history patch about the issue

Wesly: can we have an offline discussion on this issue? I've some concerns that may ease the issue first, since to find out the root cause only according to the logs is really hard, although I'm exactly trying that.

Keith: What's your repro rate of this issue? And is there any other specific steps you have, in order to repro it? After discussion w/ engineer: 1. we are not able to repro it today 2. we don't find anything abnormal in your log yet. 3. however, we are thinking about kind of workaround for your reference. Greg is helping organize the idea, once ready he will put it on bugzilla for your reference.

Hi Greg: Like discussed in phone, I think the most important thing is to make clear the risk of the workaround, so partner can make their judgement for taking it or not. In other mail partner seems has some findings and their own proposed solution too(?). So maybe yours can also give them some hint or clue, at least more reference. Anyway thanks a lot for the prompt help! (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #11) > Wesly: can we have an offline discussion on this issue? I've some concerns > that may ease the issue first, since to find out the root cause only > according to the logs is really hard, although I'm exactly trying that.

(In reply to Greg Weng [:snowmantw][:gweng][:λ][PTO:9/21~9/24|10/13~10/21] from comment #11) > Wesly: can we have an offline discussion on this issue? I've some concerns > that may ease the issue first, since to find out the root cause only > according to the logs is really hard, although I'm exactly trying that. Have you already reproduced the issue? You can contact me directly if you wan Tel: +08607558228616(In reply to Wesly Huang (TAM) from comment #13) > Hi Greg: > > Like discussed in phone, I think the most important thing is to make clear > the risk of the workaround, so partner can make their judgement for taking > it or not. In other mail partner seems has some findings and their own > proposed solution too(?). So maybe yours can also give them some hint or > clue, at least more reference. > > Anyway thanks a lot for the prompt help! > > (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #11) > > Wesly: can we have an offline discussion on this issue? I've some concerns > > that may ease the issue first, since to find out the root cause only > > according to the logs is really hard, although I'm exactly trying that. We can reproduce the issue within 2 minus by your steps. Zhangjin's suggestion may be helpful in this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1216870 But we still need more test. It will be great if any useful update from your engineers on these frozen issues.

We've reproduced the issue in Wooduck import branch. You can download it from: http://pan.baidu.com/s/1mg7xWLy

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/lock_screen_window_manager.js#L295 In closeApp: if (!this.states.enabled || !this.isActive()) { return; } What about do the following modification? if (this.isActive()) { return; }

(In reply to Keith Tu from comment #15) > We've reproduced the issue in Wooduck import branch. > You can download it from: > http://pan.baidu.com/s/1mg7xWLy Hi Keith, what's the SW you used in this video? The SW we have (Orange & TEF SW) doesn't have such lock screen (it a whole page lock, instead of your default FxOS style that just a "bar" for unlock). Currently we are not able to repro following your video, and can't see abnormal thing in the log.

Greg: Would you share your view about this modification? Thanks. (In reply to Keith Tu from comment #16) > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/ > lock_screen_window_manager.js#L295 > In closeApp: > if (!this.states.enabled || !this.isActive()) { > return; > } > What about do the following modification? > if (this.isActive()) { > return; > }

This seems what I've done for the current master, but the main point is to keep the component's state sync with the window states and the mozSetting value, and of course the CSS status on the screen and window. So to only remove one check may cause other side-effects, and which is why I wouldn't just say 'yes' firmly. I have such concern is because as I've told to Wesly, I remembered I solved this issue once, but I don't remember where the code is (it's possible in my local working branches and not merged to master after all). Anyway, the proposal is correct, just need to take care of the side-effects carefully.

hello,Wesly, the sw have sent to you by mail,please to reproduce the issue in this sw.

I can only reproduce it once on the device, but with programmatic method like set the value |false| after locking it: var settings = window.navigator.mozSettings; var lock = settings.createLock(); var result = lock.set({'lockscreen.enabled': false}); I can get the same result, and make sure this was fixed on master. That work was to make sure the status about window opening and closing is sync with the enabled state and other status. However, for 2.0 the patch is too large and risky, so I submit a proposal to close the window forcibly if the case occurs. With this patch, it should unlock the screen immediately when the value is disabled but the window still opened. I tested the method on my device via WebIDE, but since I can't easily reproduce the real case, while I don't know the proper way to flash the patched Gaia into the device, I don't know if it works well for the bug too.

Hi Deng Wei - Could you have someone to integrate the patch from Comment#21 and generate a TB to verify? Thanks

Hi Dengwei, Keith: Any news about Greg's patch in comment#21? Like said yesterday if you can still reproduce the problem pls send us the new build you used w/ the patch, thanks.

Dev has tested and the issue cannot be reproduced again. But Dev's result cannot be the final one unless it can pass PA's test. We gonna release a new SW tonight to our PA to test tomorrow. If passed, we will update the comment. Thanks!

I'm afraid the result won't be OK after out another engineer's comment. Please see the snapshots in lockscreen-NG.tar.gz. Ok.png - No probleam ko.png - The upper position (status bar) shows the background of homescreen instead all black.

Hi Keith: How's the repro. rate, and the STR? Would you still share a build for us to check? Anyway it seems to me it's a minor issue, even if we can't have a fix for this in the end. @Greg: Do you see the relation between your patch and this phenomenon?

The statusbar I believe could be fix by add a line after we close the app forcibly. And that's exactly what I mentioned to maintain the state without taking care CSS is dangerous. Fortunately it the fix is not difficult: just to set several CSS classes from the statusbar according what the normal code path follows. But it's will take some time to figure out what's the process from the code.

If new SW needed, we can provide another patched one.

You can modify the source code and push into the MS since the SW we've sent is ENG version. 1. adb pull [src] [des] 2. unpack the zip file 3. modify the source code 4. pack it 5. adb push [src] [des] Therefore, you can "build" it and test it all by yourself.

Hi Keith, DengWei: Like Greg mentioned in comment#28 you should be able to fix the status bar issue by making sure a well-sync status of css. (Also we believe this issue is quite minor) As of now we'll move Greg to other activity until more critical issue about lockscreen is found. Thanks for the understanding.

Firefox OS is not being worked on