Office : 0752-8228382（68382） DEFECT DESCRIPTION: No IMSI detach and Detach request prodecure when power off. REPRODUCING PROCEDURES: Power on the device,after device register successfully, power off the device. >From the log, we can see no IMSI detach signalling and Detach Request signalling. --KO EXPECTED BEHAVIOUR: It should have IMSI detach signalling and Detach Request signalling when the device power off. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:

Hi Gary, Partner confirmed they have patch from bug 1126677 but issue still exist. Can you help to check the new log for what is the reason? Thanks!

Hi Reporter, Is this issue always reproducible? If not, is it easier to reproduce this when there's a data call? If so, then my guess is this is a timing issue. My thoughts: If there's a data call, gecko takes more time to complete the "setRadioEnabled(false)" request. However, the code on gaia is synchronous that doesn't guarantee that |window.radio.enabled = false;| has been fully completed before starting doing power-off stuff. So, it's likely that the device is handling power-off command prior to radio-off command.

(In reply to comment #2) > Comment from Mozilla:Hi Reporter, > > Is this issue always reproducible? If not, is it easier to reproduce this when > there's a data call? If so, then my guess is this is a timing issue. > > My thoughts: If there's a data call, gecko takes more time to complete the > "setRadioEnabled(false)" request. However, the code on gaia is synchronous that > doesn't guarantee that |window.radio.enabled = false;| has been fully completed > before starting doing power-off stuff. So, it's likely that the device is > handling power-off command prior to radio-off command. > Yes,This issue always reproduce.

(In reply to sync-1 from comment #4) > (In reply to comment #2) > > Comment from Mozilla:Hi Reporter, > > > > Is this issue always reproducible? If not, is it easier to reproduce this > when > > there's a data call? If so, then my guess is this is a timing issue. > > > > My thoughts: If there's a data call, gecko takes more time to complete the > > "setRadioEnabled(false)" request. However, the code on gaia is > synchronous that > > doesn't guarantee that |window.radio.enabled = false;| has been fully > completed > > before starting doing power-off stuff. So, it's likely that the device is > > handling power-off command prior to radio-off command. > > > > Yes,This issue always reproduce. I see, thanks. Then there could be other causes, though the timing problem is still a potential one IMO.

Thank you for your help,when I close the data connection,then I test this bug,It's OK.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/radio.js#L165 https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/radio.js#L114 you can refer above link to register radiostate in sleep_menu.js, after get radio off, then issue shutdown command then. It should fix the issue.

Modify sleep_menu.js like following, it is not ok for this issue. Please help check, thanks. //tcl add begin setRadioEnabled: function sm_setRadioEnabled(conn, index) { if (window.Radio) { window.Radio.enabled = false; } }, //tcl add end /** * Begins the power off of the device. Also reboots the device if * requested. * @memberof SleepMenu.prototype * @param {Boolean} reboot Whether or not to reboot the phone. */ startPowerOff: function sm_startPowerOff(reboot) { var power = navigator.mozPower; var self = this; if (!power) { return; } // Early return if we are already shutting down. if (document.getElementById('poweroff-splash')) { return; } //tcl add begin var _mozMobileConnections = Array.prototype.slice.call(window.navigator.mozMobileConnections); var self = this; _mozMobileConnections.forEach(function(conn, index) { conn.addEventListener('radiostatechange', self.setRadioEnabled.bind(self, conn, index)); }, self); //tcl add end

Hi all, I have a quick patch, I set default timeout as 5000, please help to adjust this value to fulfill your local case. And also help me to try this patch to check does it work fine on your test? Thanks.

Hi all, After discussing with Sku, we need to check `airplane-mode` as well, radio might be not get any response when `airplane-mode` is on. So I've updated my patch, please help to try it again, thanks.

tao.li, could you please help try the patch in comment 10 again?

(In reply to Peipei Cheng (needinfo if you need my action) from comment #11) > tao.li, could you please help try the patch in comment 10 again? The result is ok. Thanks.

Thanks for the good news! GaryChen, do you know if master is affected as well? In case so, can you ask for your patch review?

Hi Beatriz, This is a quick fix for v2.0m, I think the better way to fix this issue is implement detach radio logical in gecko. Thanks.

Dear dengwei, this pr have fixed,please close this pr,TCL pr:983520.thanks.

This is only for local patch. Will not land on our code base.