Eliminate a frameback navigation initialization race #518
Conversation
During the first frameback navigation forward with `reuseFrame` set, if the client controller within the frame completes before the frame's load event fires we were previously failing to wire up our listener to handle subsequent navigations.
| if (clientController && !clientController.__parentIsListening && !clientController._previouslyRendered) { | ||
| clientController.__parentIsListening = true; | ||
| clientController.context.onLoadComplete(this._handleFrameLoad.bind(this, frame)); | ||
| if (clientController && !clientController._previouslyRendered) { |
There was a problem hiding this comment.
Can this be an else if block? or even an else block? clientController.__parentIsListening is set on the first load, as is clientController._previouslyRendered -- are the two separate checks because there's asynchrony and users may perform navigations before we've finished loading?
There was a problem hiding this comment.
Can this be an else if block? or even an else block?
It can't, actually. You'll notice that previously the bodies of the two cases were together, and the conditionals were anded. In the case where the frame's load event fires before the client controller finishes rendering we still need both to happen.
There was a problem hiding this comment.
Basically: We always need to wire up our listener (once). And, in the case where the event we're listening to hasn't fired yet, we'll bail out early and wait for it.
There was a problem hiding this comment.
there's asynchrony and users may perform navigations before we've finished loading?
It's actually just a race between the browser's load event and the client controller finishing its render. No user interaction needed.
|
lgtm 👍 |
During the first frameback navigation forward with
reuseFrameset, if theclient controller within the frame completes before the frame's load event
fires we were previously failing to wire up our listener to handle subsequent
navigations.