The bug here was quite simple: the pop callback was being invoked with the parent's context.
Flutter uses the navigation stack to know what to pop. Whenever we invoke it via Navigator.pop(context), it uses the context to derive where in the stack the method is being invoked and act accordingly.
By using the wrong context, the dialog was not being disposed of, and neither was it returning the value of the confirmation, effectively meaning the user wasn't being blocked.
With the changes done here, the feature is back to a working state: user is blocked, their messages being filtered out.
However, as described in #576, I do think that it would be useful to have more control over blocked user management:
[ ] a place to see users previously blocked (giving the user the option to unblock)
[ ] option to show/hide chats from blocked users
[ ] option to show/hide public posts from blocked users
Description
The bug here was quite simple: the
popcallback was being invoked with the parent'scontext.Flutter uses the navigation stack to know what to
pop. Whenever we invoke it viaNavigator.pop(context), it uses thecontextto derive where in the stack the method is being invoked and act accordingly.By using the wrong
context, the dialog was not being disposed of, and neither was it returning the value of the confirmation, effectively meaning the user wasn't being blocked.With the changes done here, the feature is back to a working state: user is blocked, their messages being filtered out.
However, as described in #576, I do think that it would be useful to have more control over blocked user management:
What do you think, @MathJud ?
In any case, it's not a blocker to land this fix!
Before
https://github.com/qaul/qaul.net/assets/54450520/ea0105f7-de77-4af4-be64-1eb68d2280ad
After
https://github.com/qaul/qaul.net/assets/54450520/4a1cc463-c8e4-41f1-9262-5931f1195647