fix(progress): use update_idletasks() to avoid reentrant event dispatch

ProgressWindow.update_progress_bar() and the inline progress bar in
FlightControllerInfoWindow.update_progress_bar() both called
self.progress_bar.update() to refresh the display. tkinter's update()
pumps the entire event queue, including any user clicks that arrived
against other windows while a long blocking call (parameter upload, FC
connection, parameter download, motor reset) was holding the main
thread. Those queued click handlers fire reentrantly while the caller
is still mid-operation, which can:

  - retrigger an upload/download whose state machine is not yet idle
  - close or rebuild widgets the caller still holds references to
  - dispatch destructor paths on a window the caller will dereference

Switch both call sites to update_idletasks(), which only flushes
geometry/repaint events and does not run user-event handlers. The
visible refresh of the bar and label is unchanged because progress-bar
redraw is an idle task.

Existing test_user_sees_progress_window_handle_widget_update_errors is
updated to mock update_idletasks. Added
test_progress_updates_do_not_pump_user_events as a regression guard so
a future change cannot silently restore update().

Signed-off-by: Yash Goel <yashvardhan664@gmail.com>

Author: yashhzd

ardupilot_methodic_configurator/frontend_tkinter_flightcontroller_info.py

@@ -153,8 +153,12 @@ def update_progress_bar(self, current_value: int, max_value: int) -> None:
         progress_message = _("Downloaded {} of {} parameters").format(current_value, max_value)
         self.progress_label.config(text=progress_message)
 
-        # Update the display
-        self.progress_bar.update()
+        # Update the display. update_idletasks() repaints the bar/label
+        # without re-entering the event loop; the plain update() variant
+        # would pump the full event queue (including queued user clicks
+        # against other windows) while the caller is still in the middle
+        # of a blocking parameter download.
+        self.progress_bar.update_idletasks()
         self.root.update_idletasks()
 
         # Hide progress bar when complete

ardupilot_methodic_configurator/frontend_tkinter_progress_window.py

@@ -75,7 +75,11 @@ def __init__(  # pylint: disable=too-many-arguments, too-many-positional-argumen
             # Show the window now that it's properly positioned
             self.progress_window.lift()
             self._shown = True
-            self.progress_bar.update()
+            # Use update_idletasks() rather than update(): the latter pumps the
+            # full event queue (including queued mouse clicks against other
+            # windows) and can re-enter user-event handlers while the caller
+            # is still in the middle of a blocking I/O operation.
+            self.progress_bar.update_idletasks()
 
     def _center_progress_window(self) -> None:
         """
@@ -133,7 +137,11 @@ def update_progress_bar(self, current_value: int, max_value: int) -> None:
                 # Update the progress message
                 self.progress_label.config(text=self.message.format(current_value, max_value))
 
-                self.progress_bar.update()
+                # update_idletasks() repaints the bar/label without re-entering
+                # the event loop. The plain update() variant processes pending
+                # user events (clicks, keypresses) which can fire callbacks on
+                # other windows while a blocking upload/download is in flight.
+                self.progress_bar.update_idletasks()
 
                 # Close the progress window when the process is complete
                 if current_value == max_value:

tests/test_frontend_tkinter_progress_window.py

@@ -247,8 +247,8 @@ def test_user_sees_progress_window_handle_widget_update_errors(self, progress_wi
         WHEN: Progress updates fail due to widget errors
         THEN: Errors are logged but no exceptions are raised
         """
-        # Mock progress_bar.update to raise TclError
-        progress_window.progress_bar.update = MagicMock(side_effect=tk.TclError("Widget destroyed"))
+        # Mock progress_bar.update_idletasks to raise TclError
+        progress_window.progress_bar.update_idletasks = MagicMock(side_effect=tk.TclError("Widget destroyed"))
 
         with patch("ardupilot_methodic_configurator.frontend_tkinter_progress_window.logging_error") as mock_logging:
             # This should not raise an exception
@@ -258,6 +258,28 @@ def test_user_sees_progress_window_handle_widget_update_errors(self, progress_wi
             mock_logging.assert_called_once()
             assert "Updating progress widgets" in mock_logging.call_args[0][0]
 
+    def test_progress_updates_do_not_pump_user_events(self, progress_window) -> None:
+        """
+        Progress updates must use update_idletasks(), not update().
+
+        GIVEN: A blocking I/O operation (param upload, FC connection, etc.) is
+            running on the main thread and periodically calling
+            update_progress_bar to refresh the bar.
+        WHEN: The progress window is initialised and then updated.
+        THEN: Only update_idletasks() is called on the progress bar. The
+            full update() variant pumps the entire event queue and would
+            re-dispatch user clicks that arrived during the blocking call,
+            allowing reentrant button callbacks while the caller is still
+            in the middle of upload/connection logic.
+        """
+        progress_window.progress_bar.update = MagicMock()
+        progress_window.progress_bar.update_idletasks = MagicMock()
+
+        progress_window.update_progress_bar(25, 100)
+
+        progress_window.progress_bar.update.assert_not_called()
+        progress_window.progress_bar.update_idletasks.assert_called()
+
     def test_user_sees_progress_window_handle_lazy_window_relift(self, progress_window) -> None:
         """
         User sees progress window handle relifting for already shown windows.