Confirmed, it sure does behave badly. Looks like it's not 'captured' in any way like the dialogs on partitioning (for e.g.) are. I'm at least +1 FE to this, and I think that'd be uncontroversial, for anaconda team's benefit.

We still don't have solution for the issue, the main problem is that the network configuration window belongs to a separate process (nm-connection-editor). There already is bug #876020 filed.

However, Vratislav came up with IMO reasonable idea for workaround - don't make Configure button insensitive when nm-c-e is run, rather allow clicking the button to kill any existing (in this case hidden) dialog and run a new one.

Here is updates image to try with TC-2:
http://rvykydal.fedorapeople.org/updates.nmcefocus.img

How about alt+tab? How about combining the network spoke and the location time zone? Maybe that might save some memory and time left taking to configure the install? How about moving it to the main screen? How about not greying out the configure button when the window is open? That way when you click the configure button it just reactivates the window?

All reasonable thoughts.

"How about alt+tab? How about combining the network spoke and the location time zone? Maybe that might save some memory and time left taking to configure the install? How about moving it to the main screen?"

How would any of those thoughts help anything at all? The fundamental issue is that it's launching a separate process, and that's coming up as a proper window, and we can't make it a 'captured' (don't know the right term) window like the partitioning ones are because it's really a separate process, and one that's a fully-fledged app in its own right (nm-c-e). Nothing you mentioned there would help at all.

"How about not greying out the configure button when the window is open?"

That's, erm, precisely what Radek wrote, and what the updates image he posted does.

For the record, Alt+Tab functionality was intentionally removed (bug #858686).

Discussed at 2013-06-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-12/f19final-blocker-review-5.2013-06-12-16.01.log.txt . The general feeling on this was that it's not likely to come up enough or screw people up badly enough to be a blocker (it doesn't directly hit any of the criteria, so it'd be a very conditional violation of 'must be able to install'), but it's accepted as a freeze exception issue.

Screencasts:
current behaviour: http://rvykydal.fedorapeople.org/nmcestacking_current.webm
patched: http://rvykydal.fedorapeople.org/nmcestacking.webm

pykickstart-1.99.32-1.fc19,python-blivet-0.16-1.fc19,anaconda-19.30.6-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/pykickstart-1.99.32-1.fc19,python-blivet-0.16-1.fc19,anaconda-19.30.6-1.fc19

(In reply to Radek Vykydal from comment #7)
> Screencasts:
> current behaviour: http://rvykydal.fedorapeople.org/nmcestacking_current.webm
> patched: http://rvykydal.fedorapeople.org/nmcestacking.webm

Loosk good!

Package anaconda-19.30.7-1.fc19, pykickstart-1.99.32-1.fc19, python-blivet-0.16-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.30.7-1.fc19 pykickstart-1.99.32-1.fc19 python-blivet-0.16-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10913/pykickstart-1.99.32-1.fc19,python-blivet-0.16-1.fc19,anaconda-19.30.7-1.fc19
then log in and leave karma (feedback).

pykickstart-1.99.32-1.fc19, python-blivet-0.16-1.fc19, anaconda-19.30.8-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.