STR: 1. Download latest Firefox Beta (3.0b3) build 2. Launch App 3. Navigate to settings and log into FxA 4. Wait ~10 seconds for logins to get pulled down 5. Tap logins Expected: Logins appear loading and appear Actual: Login loading spinner spins but buttons and app is frozen. ------ After some initial investigation, I found that this gets printed in the log upon entering logins: Mar 7 15:52:34 iPhone Client <Error>: objc: Cannot form weak reference to instance (0x128158a00) of class Client.LoginTableViewCell. It is possible that this object was over-released, or is in the process of deallocation. I believe this is what would be causing the 'freeze' but not crashing the app.
status-fxios-v2.0: --- → unaffected
status-fxios-v3.0: --- → affected
Note: running from Xcode using the same code doesn't cause the crash or error to appear. Might be something related to code optimization (yay)
Yup - turning on fast -O/-Os optimization that we use for our release builds causes this issue.
Fun fact: No code changes since 2.0 in LoginListViewController/LoginTableViewCell and it works in the current production build which was built using Xcode 7.2.1 Checking out the same tag and building now causes the issue.
I'll try to find time to look at this.
tracking-fxios: ? → 3.0+
Investigate bindings to data source for cell or delegates during dequeuing.
Assignee: nobody → sleroux
Status: NEW → ASSIGNED
Commenting out https://github.com/mozilla/firefox-ios/blob/master/Client/Frontend/Widgets/LoginTableViewCell.swift#L206 until the end of that switch case closure works.
Created attachment 8730742 [details] [review] Github PR
Attachment #8730742 - Flags: review?(bnicholson)
Comment on attachment 8730742 [details] [review] Github PR Wonder if this is related to our lazy block init pattern we're using? This bug is a bit concerning since there's no compiler error, and no crash log is sent to us, so I have no idea where else this might be happening...
Attachment #8730742 - Flags: review?(bnicholson) → review+
Might be related to how the SnapKit closures capture their vars. Early in my testing if I commented out the constraint setup code for the highlight/description labels things seemed to work fine even if it was not public scoped. I also just found out about the @noescape keyword  with closures in Swift and it looks like SnapKit makes use of that when calling snp_makeConstraints. If I had to guess, the compiler is optimizing out the strong ref caused by the @noescape block for the lazy property. Its annoying that this works everywhere else but for some reason not here... I'm going to file a follow up bug to dig in a bit more.  http://krakendev.io/blog/hipster-swift
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-fxios-v4.0: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 4.0
Pointer to follow up investigation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257191
status-fxios-v3.0: affected → fixed
Tested on build 4.0.0b1 and 3.0b11 The issue has been fixed and logins can be accessed.
Status: RESOLVED → VERIFIED
status-fxios-v3.0: fixed → verified
status-fxios-v4.0: fixed → verified
You need to log in before you can comment on or make changes to this bug.