Several things can cause a single view[] event to be pumped to a card:
- Exiting editing tools/switching to Interact mode
- Exiting the Listener
- Dismissing a modal dialog, including an alert[] box
- Initially opening a deck
- Navigating to a card with go[], by setting deck.card, or manually using navigation keyboard shortcuts (some of which can be intercepted in navigate[])
That last one is a little tricky, since a phrase like "go[card]" will effectively schedule a view[] event for the next frame. Thus, one possible idiom for driving continuous animation on a card looks like:
on view do # some animation code... go[card] end
Unhandled events "bubble": if there's no "on view do ... end" in an animated widget's script, the event will be offered to the card, and then the deck in turn.
There is a known issue in v1.36 in which contraptions can (erroneously) bubble their internal events to the containing card, which can lead to some mischief, though it doesn't sound like the problem you're describing is related. This is already patched in the version of web-decker on beyondloom.
Because there are many things other than explicitly "visiting" a card which can fire a view[] event, it is generally not a good idea to use it for code which is intended to run exactly once. There's some discussion of that problem in this thread which might be relevant.