Distinguish between user-triggered events and gradio-triggered events

[omerXfaruq]

Describe the bug

Created a hacky blocks party space for fun, but did not work as intended, creates infinite recursion with events triggering each other.
Question: Is there a way we can avoid this? @aliabid94, @pngwn

Is there an existing issue for this?

• I have searched the existing issues

Reproduction

https://huggingface.co/spaces/Gradio-Blocks/Hacky-Blocks-Party

Screenshot

Logs

No logs

System Info

spaces

Severity

annoying

[pngwn]

What would you expect to happen here? It looks like you've explicitly coded the recursion in.

[omerXfaruq]

I actually didn't expect that the events were going to trigger each other. Thought changes other than the user made in the UI were not triggering the events.

[abidlabs]

Agreed with @farukozderim -- I think the change() event should only be called if a user makes a change, not if a component is changed due to another event.

[abidlabs]

I think we can close this issue now. We now support this for many components using .select() event trigger (which only fires if a user manually selects an option). We can also only fire an event if there's a programmatic change to a value using .then().

Haven't seen any real-world use cases of the kind of recursion described in the issue above. But even that can be achieved (albeit in a somewhat hacky way) using cancels:

import gradio as gr

with gr.Blocks() as demo:
    a = gr.Textbox()
    b = gr.Textbox()
    
    ev1 = a.change(lambda x:x, a, b)
    ev2 = b.change(lambda x:x, b, a)
    a.change(None, None, None, cancels=ev2)
    b.change(None, None, None, cancels=ev1)
    
demo.queue().launch()