When a page contains two elements carrying the same data-native-* signal, the bridge takes the first one and ignores the rest, silently. There is no warning in development, no console message, nothing in the docs saying which one wins.
Two ways an app hits this without doing anything obviously wrong:
- A partial rendering
native_navbar_tag gets included twice, or a layout and a page both emit tabs.
- A turbo-frame accidentally loads a full page rather than a frame response, which drops a second copy of the whole layout into the host document. That page's signals then compete with the host's, and the wrong navbar or badge can win.
Both present as "the native chrome is showing something from a different screen," which is a long way from the cause.
Ask
A development-only console warning naming the duplicated attribute and the count, emitted from the shared JS when it scrapes. Development only, since a production app should not pay for the check and cannot act on the message. A gem-side check would only see one render pass, so the JS is the right place.
Surfaced by the signal pipeline audit that drove the 0.12.0 hardening pass.
When a page contains two elements carrying the same
data-native-*signal, the bridge takes the first one and ignores the rest, silently. There is no warning in development, no console message, nothing in the docs saying which one wins.Two ways an app hits this without doing anything obviously wrong:
native_navbar_taggets included twice, or a layout and a page both emit tabs.Both present as "the native chrome is showing something from a different screen," which is a long way from the cause.
Ask
A development-only console warning naming the duplicated attribute and the count, emitted from the shared JS when it scrapes. Development only, since a production app should not pay for the check and cannot act on the message. A gem-side check would only see one render pass, so the JS is the right place.
Surfaced by the signal pipeline audit that drove the 0.12.0 hardening pass.