All users were logged out of Bugzilla on October 13th, 2018
Current code checks whether network.online is locked - except Firefox doesn't really give a ... about this pref, it uses browser.offline for all its state checking - meaning that checking whether this pref is locked is (a) wrong and (b) useless. At least, that's how I read the code in the URL, and a lxr for "network.online"
It looks to me like locking the pref is just a means of disabling the "work offline" menuitem, regardless of offline state.
Why not check the lock on the browser's own pref, though? There it would make sense, now it's actually possible for a user to go offline/online anyway, even though the UI might be disabled.
(In reply to comment #2) > Why not check the lock on the browser's own pref, though? There it would make > sense, now it's actually possible for a user to go offline/online anyway, even > though the UI might be disabled. Locking the pref used to store state would interfere with the chrome code's ability to modify it. The io service needs to be able to track offline state whether or not the user should be "allowed" to go offline.
The ioservice doesn't touch that pref at all. Only the UI code does, and the UI code is currently disabled if some *other* pref is locked, meaning it requires locking two prefs to actually stop the user from changing the offline state. Locking both these prefs still won't prevent the ioservice from doing whatever it wants to be doing.
Re-reading this, I'm pretty sure this is invalid.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.