Accessing logins after signing into FxA causes screen to freeze the app

VERIFIED FIXED in 4.0

Status

()

Firefox for iOS
General
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: sleroux, Assigned: sleroux)

Tracking

({regression, reproducible})

unspecified
Other
iOS
regression, reproducible

Firefox Tracking Flags

(fxios-v2.0 unaffected, fxios-v3.0 verified, fxios-v4.0 verified, fxios3.0+)

Details

Attachments

(1 attachment)

48 bytes, text/x-github-pull-request
bnicholson
: review+
Details | Review | Splinter Review
(Assignee)

Description

2 years ago
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[256] <Error>: objc[256]: 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.
(Assignee)

Updated

2 years ago
status-fxios-v2.0: --- → unaffected
status-fxios-v3.0: --- → affected
(Assignee)

Comment 1

2 years ago
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)
(Assignee)

Comment 2

2 years ago
Yup - turning on fast -O/-Os optimization that we use for our release builds causes this issue.
(Assignee)

Comment 3

2 years ago
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+
Flags: needinfo?(rnewman)
(Assignee)

Comment 5

2 years ago
Investigate bindings to data source for cell or delegates during dequeuing.
(Assignee)

Updated

2 years ago
Assignee: nobody → sleroux
Status: NEW → ASSIGNED
(Assignee)

Comment 6

2 years ago
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.
Flags: needinfo?(rnewman)

Updated

2 years ago
Duplicate of this bug: 1255030

Updated

2 years ago
Keywords: regression, reproducible
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1255430
(Assignee)

Comment 9

2 years ago
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+
(Assignee)

Comment 11

2 years ago
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 [1] 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.

[1] http://krakendev.io/blog/hipster-swift
(Assignee)

Comment 12

2 years ago
master 057da44099858adeb677d91c1c4c8900d207b6f2
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-fxios-v4.0: --- → fixed
Resolution: --- → FIXED
Whiteboard: [needsuplift]
Target Milestone: --- → 4.0
(Assignee)

Comment 13

2 years ago
Pointer to follow up investigation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257191
(Assignee)

Comment 14

2 years ago
v3.x 1e43f69
status-fxios-v3.0: affected → fixed
Whiteboard: [needsuplift]
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

Updated

2 years ago
Duplicate of this bug: 1266958
You need to log in before you can comment on or make changes to this bug.