ok, i think i have a log where i got a stuck asui net window.
I found it!
There is absolutely no dbus thread activity after it opens the blank window for the last time. I'm guessing it never receives the MapNotify for the blank window so it spins forever waiting for the blank window to map. It would be possible for the main thread to steal away the MapNotify event if the scheduler switches threads but none of the events received by main (in your log) are the MapNotify. Luckily, the first test I ran showed the main loop waking up and grabbing that map event.
I've added a hack in the test/debug builds that suspends event processing in the main loop while waiting for the MapNotify on the blank window. When I feel better I'll add a separate event processing loop for the blank window. Let me know if it still gets stuck open.
Does the first string contain your connection name?
The GUID is returned for me. This thread seems to indicate that the connection name was used prior to Diablo and also gives some examples for getting the ESSID:
I've added a hack in the test/debug builds that suspends event processing in the main loop while waiting for the MapNotify on the blank window. When I feel better I'll add a separate event processing loop for the blank window. Let me know if it still gets stuck open.
Not entirely sure, but i get the feeling that it has gotten "worse". That is, i no longer need to mess with the power button to get the asui net window to eat all screen taps.
btw, this seems easier to provoke when having the screen black set to say 30 seconds then 2 minutes (my preferred as it rarely gets in the way of reading a longer text).