@vardhan30016 Could you explain how this fixes #10912?

@CatchABus Thanks for the question! Here is how this PR fixes #10912:

The root issue in #10912 is that when navigating into a component wrapped in a ProxyViewContainer, the page does not receive the expected NavigationEntry.context.
Because the context was not forwarded in several navigation flows, the resolved page ended up with:

page._navigationContext = undefined

page.bindingContext = undefined (when no explicit bindingContext was provided)

Why this breaks hidden in ProxyViewContainer

ProxyViewContainer relies on the final resolved page’s bindingContext to evaluate UI properties such as hidden.
Since the page never received the navigation context, the internal bindings for the template evaluate incorrectly — causing the hidden property to fail.

This is why the behavior looks inconsistent: the component renders, but reactive properties (hidden, etc.) cannot evaluate without a valid binding context.

How this PR fixes it

This PR ensures that in all navigation paths, we now forward:

entry.context → page._navigationContext

entry.context → page.bindingContext
(only when the page does not already have a bindingContext and none was passed explicitly)

And this happens before _onNavigatingTo(), so the page lifecycle receives the correct context.

Result

With the binding context properly set:

ProxyViewContainer receives valid binding state

hidden resolves correctly

the UI updates as expected

the bug in #10912 no longer reproduces

This makes navigation context handling consistent and restores correct data-driven UI behavior — including the hidden property.

@vardhan30016 Could you explain how this fixes #10912?

@CatchABus Thanks for the question! Here is how this PR fixes #10912:

The root issue in #10912 is that when navigating into a component wrapped in a ProxyViewContainer, the page does not receive the expected NavigationEntry.context.
Because the context was not forwarded in several navigation flows, the resolved page ended up with:

page._navigationContext = undefined

page.bindingContext = undefined (when no explicit bindingContext was provided)

Why this breaks hidden in ProxyViewContainer

ProxyViewContainer relies on the final resolved page’s bindingContext to evaluate UI properties such as hidden.
Since the page never received the navigation context, the internal bindings for the template evaluate incorrectly — causing the hidden property to fail.

This is why the behavior looks inconsistent: the component renders, but reactive properties (hidden, etc.) cannot evaluate without a valid binding context.

How this PR fixes it

This PR ensures that in all navigation paths, we now forward:

entry.context → page._navigationContext

entry.context → page.bindingContext
(only when the page does not already have a bindingContext and none was passed explicitly)

And this happens before _onNavigatingTo(), so the page lifecycle receives the correct context.

Result

With the binding context properly set:

ProxyViewContainer receives valid binding state

hidden resolves correctly

the UI updates as expected

the bug in #10912 no longer reproduces

This makes navigation context handling consistent and restores correct data-driven UI behavior — including the hidden property.

@vardhan30016 Could you explain how this fixes #10912?

@CatchABus Thanks for the question! Here is how this PR fixes #10912:

The root issue in #10912 is that when navigating into a component wrapped in a ProxyViewContainer, the page does not receive the expected NavigationEntry.context. Because the context was not forwarded in several navigation flows, the resolved page ended up with:

page._navigationContext = undefined

page.bindingContext = undefined (when no explicit bindingContext was provided)

Why this breaks hidden in ProxyViewContainer

ProxyViewContainer relies on the final resolved page’s bindingContext to evaluate UI properties such as hidden. Since the page never received the navigation context, the internal bindings for the template evaluate incorrectly — causing the hidden property to fail.

This is why the behavior looks inconsistent: the component renders, but reactive properties (hidden, etc.) cannot evaluate without a valid binding context.

How this PR fixes it

This PR ensures that in all navigation paths, we now forward:

entry.context → page._navigationContext

entry.context → page.bindingContext (only when the page does not already have a bindingContext and none was passed explicitly)

And this happens before _onNavigatingTo(), so the page lifecycle receives the correct context.

Result

With the binding context properly set:

ProxyViewContainer receives valid binding state

hidden resolves correctly

the UI updates as expected

the bug in #10912 no longer reproduces

This makes navigation context handling consistent and restores correct data-driven UI behavior — including the hidden property.

This still doesn't look relevant to the missing handling of ProxyViewContainer hiding its children and if you check the issue sample, the author didn't use binding context.

• Property bindingContext is flavor-specific and belongs to plain TS/JS apps. On the contrary, it's something we would ideally decouple from @nativescript/core in the next few years.
• Navigation context is general-purpose and users can share literally anything while navigating between pages.
  If you want to use the navigation context as binding context, it's up to you as a user to assign it when navigation events are fired.
  Example:

@vardhan30016 Could you explain how this fixes #10912?

@CatchABus Thanks for the question! Here is how this PR fixes #10912:
The root issue in #10912 is that when navigating into a component wrapped in a ProxyViewContainer, the page does not receive the expected NavigationEntry.context. Because the context was not forwarded in several navigation flows, the resolved page ended up with:
page._navigationContext = undefined
page.bindingContext = undefined (when no explicit bindingContext was provided)
Why this breaks hidden in ProxyViewContainer
ProxyViewContainer relies on the final resolved page’s bindingContext to evaluate UI properties such as hidden. Since the page never received the navigation context, the internal bindings for the template evaluate incorrectly — causing the hidden property to fail.
This is why the behavior looks inconsistent: the component renders, but reactive properties (hidden, etc.) cannot evaluate without a valid binding context.
How this PR fixes it
This PR ensures that in all navigation paths, we now forward:
entry.context → page._navigationContext
entry.context → page.bindingContext (only when the page does not already have a bindingContext and none was passed explicitly)
And this happens before _onNavigatingTo(), so the page lifecycle receives the correct context.
Result
With the binding context properly set:
ProxyViewContainer receives valid binding state
hidden resolves correctly
the UI updates as expected
the bug in #10912 no longer reproduces
This makes navigation context handling consistent and restores correct data-driven UI behavior — including the hidden property.

This still doesn't look relevant to the missing handling of ProxyViewContainer hiding its children and if you check the issue sample, the author didn't use binding context.

@CatchABus Thanks for the clarification — here is the concise reason this fix is still relevant to #10912:

The issue in #10912 happens because the navigation context arrives too late in some navigation flows.
Even when the user does not manually use bindingContext, ProxyViewContainer still evaluates its children based on the state of the resolved Page at that moment.

When NavigationEntry.context isn’t forwarded early:

the Page receives undefined navigation state

ProxyViewContainer evaluates before that state is available

which produces the inconsistent hidden behavior shown in the issue

This PR makes the context consistently available before _onNavigatingTo(), so ProxyViewContainer has the correct state during its evaluation.
The patch doesn’t change any public behavior — it only ensures the navigation context is reliably present, which resolves the timing issue behind #10912.

Hi @CatchABus — just following up.

I've applied all your feedback and clarified the reasoning behind the fix.
To summarize the key point for #10912:

The issue is not about bindingContext usage by the user — it’s about the
navigation context arriving too late for ProxyViewContainer’s internal
evaluation.
This PR ensures NavigationEntry.context is consistently available before
_onNavigatingTo(), which resolves the timing gap that causes hidden to be
evaluated incorrectly.

The change is fully backward-compatible, touches no public API, and only
stabilizes the navigation-state propagation logic.

If everything looks good, could you please review/approve the workflows so it
can be merged?
I’d really appreciate it — I’m trying to get this fix landed today so I can
continue with related navigation work.

Thanks again for your guidance and time!