New issue
Advanced search Search tips

Issue 912382 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
marq@chromium.org
gambard@chromium.org
eugene...@chromium.org
edchin@chromium.org
kkhorimoto@chromium.org
ios-bugs@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 3
Type: Bug
DetectionType: User



Sign in to add a comment

[iOS] NamedGuides should be added to the window.

Project Member Reported by kkhorimoto@chromium.org, Dec 5 
There have been several bugs that arose from NamedGuide usage stemming from not being able to tell when a view is within the same hierarchy as the NamedGuides.  One example is Issue 907485, where we were unable to detect when a view was removed from the NamedGuide's hierarchy, leading to a crash.

Issue 907485 can be fixed by listening to window changes as a trigger to check whether the NamedGuides are in the view's current hierarchy.  This fix works because the view is always either A) not in a window, or B) in a window and a subview of BVC, so listening to window changes are effectively the same as listening to being added/removed from BVC's hierarchy.  This is not guaranteed, however, as NamedGuides are not explicitly guaranteed to be added to the BVC.

One solution to make NamedGuide usage more robust is to explicitly add them directly to the window, so any UIViews that uses NamedGuides for their layout can use |-didMoveToWindow| as a reliable trigger for NamedGuide updates.

Comment 1 by gambard@chromium.org, Dec 6 

I am not sure about that. It means that the NamedGuide would be shared between the incognito and non-incognito.
Each time you move to a non-nil window all the named-guide based constraints need to be reset. I wonder when you change BVC (so one is removed to the window the other is added) if the fact that you use the same named guide would induce a visible frame change.

Maybe the solution would be to never activate the constraints using named guide (i.e. you recreate them every time by walking the view hierarchy).

Comment 2 by thegreenfrog@chromium.org, Dec 6

Status: Available (was: Untriaged)

Comment 3 by kkhorimoto@chromium.org, Dec 6 

Hmm that's a good point about having to deactivate/reactivate the constraints every time the window changes.  Maybe we could create an NSLayoutConstraint subclass specific to NamedGuides such that this behavior is handled internally by the constraint?  I'm not sure how feasible it is to fix this by requiring all constraints that use NamedGuides to be recreated rather than deactivated/reactivated.  It'd be difficult to enforce this in code, and relying on "best practices" for NamedGuide usage allows for future bugs like this to occur.
►

Sign in to add a comment