I'm afraid this is a problem in the mate-window-manager, the Initial Setup just uses the 'anaconda' and 'anaconda-widgets' packages that call gtk_window_maximize [1][2] to make the window maximized. 

[1] https://git.fedorahosted.org/cgit/anaconda.git/tree/widgets/src/BaseWindow.c#n208
[2] https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-maximize

I'm reassigning this bug to the mate-window-manager component. If anybody thinks this should be resolved in initial-setup (or anaconda-widget), please reassign it back and suggest the possible solution.

mate-window-manager simply displays what you tell it to. Note that it is GTK2 based. If you can find a bug with the code or a patch that I can apply let me know.

Note that mate-window-manager (marco) is a fork of metacity 2.32

In fact I don't even understand why initial-setup is run when all of these things are done during the install via anaconda. 

initial-setup runs and it's like "okay! I'm going to do what you told me to do in Anaconda!" 

Also note that this was not a problem with firstboot.

(In reply to comment #2)
> mate-window-manager simply displays what you tell it to. Note that it is
> GTK2 based. If you can find a bug with the code or a patch that I can apply
> let me know.
Well, obviously it doesn't, as after calling 'gtk_window_maximize' the window is not maximized. I have no idea, how this can be fixed, but it is not a bug in the initial-setup. 

Maybe this wasn't a problem with firstboot, because it a had a lot of hacks to deal with similar bugs. We really don't want to go that way with the anaconda (because that's where the affected code lives).

The reasons why the initial-setup runs are OEM installations and screens that can be run only after the installation. I will work on a patch to prevent it from showing up if nothing more can be done there.

I've just tested KDE, Xfce and LXDE and with all their window managers, it works as expected.

Now that I've tested Mate, it worked as well.

I vaguely recall a lingering similar issue back with firstboot/kwin, and the problem then was that sometimes firstboot's spawning of X/kwin didn't wait until kwin was done loading before issuing window resizing calls.

See bug #821077 (starting at comment 43) for that past issue.

Perhaps something similar is happening here too.

(In reply to comment #7)
> Now that I've tested Mate, it worked as well.

Let's wait for some dust to settle and test it again.

I reproduced this with the test live image I composed today. I think Rex's comment #8 may be on point here.

(In reply to Rex Dieter from comment #8)
> I vaguely recall a lingering similar issue back with firstboot/kwin, and the
> problem then was that sometimes firstboot's spawning of X/kwin didn't wait
> until kwin was done loading before issuing window resizing calls.
> 
> See bug #821077 (starting at comment 43) for that past issue.
> 
> Perhaps something similar is happening here too.
Yeah, I guess it is. But what can I do to prevent such issue? What the i-s does is running this:

> /bin/xinit /bin/firstboot-windowmanager /bin/initial-setup -- /bin/Xorg :9 -ac -nolisten tcp

where the /bin/firstboot-windowmanager [1] starts the window manager and the i-s's process.

[1] https://git.fedorahosted.org/cgit/initial-setup.git/tree/firstboot-windowmanager

Shall I add some sleep between starting the WM and the i-s's process?

Here's the one fix/workaround firstboot used from bug #821077 :

https://bugzilla.redhat.com/show_bug.cgi?id=821077#c61

mate-window-manager-1.6.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mate-window-manager-1.6.1-2.fc19

I did test today mate-window-manager-1.6.1-2.fc19 with TC2 netinstall (desktop MATE) , but it doesn't help.
The only way to get i-s correct working is to install metacity before i-s is running.
But honestly, why you forcing others desktops to use metacity and adding it to their comps groups?
If anaconda would forced a user creation, there would be no reason to run i-s for MATE.
And why should anaconda doesn't do that?
Sorry, i see no reason for not to do this.
Inside MATE we have system-config-users to create other accounts.
If any other desktop want to use this redundant application they can add i-s to their comps groups.
Pls do not compromise MATE in f19 release with a broken application.

MATE packager and upstream

PS:
For me this is a blocker!

(In reply to Wolfgang Ulbrich from comment #14)
> I did test today mate-window-manager-1.6.1-2.fc19 with TC2 netinstall
> (desktop MATE) , but it doesn't help.
> The only way to get i-s correct working is to install metacity before i-s is
> running.
> But honestly, why you forcing others desktops to use metacity and adding it
> to their comps groups?
> If anaconda would forced a user creation, there would be no reason to run
> i-s for MATE.
> And why should anaconda doesn't do that?
> Sorry, i see no reason for not to do this.
> Inside MATE we have system-config-users to create other accounts.
> If any other desktop want to use this redundant application they can add i-s
> to their comps groups.
> Pls do not compromise MATE in f19 release with a broken application.
> 
> MATE packager and upstream

^^ GOOD points 

(In reply to Vratislav Podzimek from comment #11)
> (In reply to Rex Dieter from comment #8)
> > I vaguely recall a lingering similar issue back with firstboot/kwin, and the
> > problem then was that sometimes firstboot's spawning of X/kwin didn't wait
> > until kwin was done loading before issuing window resizing calls.
> > 
> > See bug #821077 (starting at comment 43) for that past issue.
> > 
> > Perhaps something similar is happening here too.
> Yeah, I guess it is. But what can I do to prevent such issue? What the i-s
> does is running this:
> 
> > /bin/xinit /bin/firstboot-windowmanager /bin/initial-setup -- /bin/Xorg :9 -ac -nolisten tcp
> 
> where the /bin/firstboot-windowmanager [1] starts the window manager and the
> i-s's process.
> 
> [1]
> https://git.fedorahosted.org/cgit/initial-setup.git/tree/firstboot-
> windowmanager
> 
> Shall I add some sleep between starting the WM and the i-s's process?

Don't do anything now. Next time realize there are other DEs besides Gnome and KDE and test all of them.

metacity was added to comps for MATE.

Package mate-window-manager-1.6.1-2.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 mate-window-manager-1.6.1-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10448/mate-window-manager-1.6.1-2.fc19
then log in and leave karma (feedback).

Wolfgang: no-one said anything about forcing anyone to use metacity for anything. Dan may have decided to use that as a workaround for this bug, but no-one asked, told or forced him to...

On your other question, see https://bugzilla.redhat.com/show_bug.cgi?id=965797 .

Adam,
(In reply to Adam Williamson from comment #19)
> Wolfgang: no-one said anything about forcing anyone to use metacity for
> anything. Dan may have decided to use that as a workaround for this bug, but
> no-one asked, told or forced him to...
I'm still wondering about this....
> 
> On your other question, see
> https://bugzilla.redhat.com/show_bug.cgi?id=965797 .
Ok, seems there is a future plan to add addons for i-s, hope we need this for working desktop.

But in my my opinion adding metacity to comps for MATE is a workaround and doesn't fix the real issue.
I-s have to work also with marco.
So, no need to close this bug with a updated package which didn't fix the issue.

mate-window-manager-1.6.2-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mate-window-manager-1.6.2-2.fc19

Dan submitted the update and chose to mark it as 'fixing' this bug, which causes Bodhi to automatically transfer the bug to MODIFIED, ON_QA, then CLOSED as the update moves through the process. It was his choice to do so. Having said that, I agree that it would make sense to keep the bug open after that update is pushed, with the summary suitably modified.

*** Bug 973997 has been marked as a duplicate of this bug. ***

mate-window-manager-1.6.2-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Guys, I don't want to start a flame here so I won't reassign this to the mate-window-manager, but I still have no idea how should I fix this issue. The i-s/anaconda do what they are supposed to do, even the way that fixed the issues with kwin and still this is not fixed. If you really think this is an i-s issue, please suggest a way to fix it. I really don't understand 'marco' to that extent and I really have no idea what might be going wrong, especially if it is a fork of metacity which works okay.

(In reply to Vratislav Podzimek from comment #25)
> Guys, I don't want to start a flame here so I won't reassign this to the
> mate-window-manager, but I still have no idea how should I fix this issue.
> The i-s/anaconda do what they are supposed to do, even the way that fixed
> the issues with kwin and still this is not fixed. If you really think this
> is an i-s issue, please suggest a way to fix it. I really don't understand
> 'marco' to that extent and I really have no idea what might be going wrong,
> especially if it is a fork of metacity which works okay.

marco is just a fork of metacity with a different name. 

maybe just add a few lines of code that looks for metacity? in the spec file should it still say provides firstboot(windowmanager) = x or initial-setup(windowmanager) = x  now?

(In reply to Dan Mashal from comment #26)
> (In reply to Vratislav Podzimek from comment #25)
> > Guys, I don't want to start a flame here so I won't reassign this to the
> > mate-window-manager, but I still have no idea how should I fix this issue.
> > The i-s/anaconda do what they are supposed to do, even the way that fixed
> > the issues with kwin and still this is not fixed. If you really think this
> > is an i-s issue, please suggest a way to fix it. I really don't understand
> > 'marco' to that extent and I really have no idea what might be going wrong,
> > especially if it is a fork of metacity which works okay.
> 
> marco is just a fork of metacity with a different name. 
> 
> maybe just add a few lines of code that looks for metacity? in the spec file
> should it still say provides firstboot(windowmanager) = x or
> initial-setup(windowmanager) = x  now?
I mean the issue is fixed because the i-s first tries to find and run metacity which succeeds now that it is in the MATE's comps. But the issue with the marco (which is the thing this bug targets now) is not fixed in any way. I didn't explain myself well, sorry. 

'firstboot(windowmanager)' is still the right string for the spec.

Okay. Please add support for "marco" if possibly. Probably don't want to be pulling in metacity.

(In reply to Vratislav Podzimek from comment #25)
> Guys, I don't want to start a flame here so I won't reassign this to the
> mate-window-manager, but I still have no idea how should I fix this issue.
> The i-s/anaconda do what they are supposed to do, even the way that fixed
> the issues with kwin and still this is not fixed. If you really think this
> is an i-s issue, please suggest a way to fix it. I really don't understand
> 'marco' to that extent and I really have no idea what might be going wrong,
> especially if it is a fork of metacity which works okay.

Maybe the subject of the topic is a bit worse ( feel free to change it if you can confirm), because i did some further testings.

In my current f19 installation on baremetal (since pre alpha), where no other windows-manager is installed as mate-window-manager (binary marco), i can start i-s from inside MATE and it displayed well with marco.

In runlevel 3 i can start i-s with 'systemctl start initial-setup-graphical.service' and it displayed well with marco.

For confirming my results i did edit the /usr/bin/firstboot-windowmanager script.
change
WMS=("metacity" "kwin" "xfwm4" "openbox" "marco")
to
WMS=("marco")

Same results in runlevel 3 :)

So i think i-s and m-w-m are married, maybe it is a prob on slow VM's where all people test f19.
Maybe it is possible to edit the old firstboot-windowmanager script, you can also called for marco with gsettings
rave@mother ~]$ gsettings get org.mate.session.required-components windowmanager | cut -d\' -f2
marco

Maybe this is a solution.

Sorry, i can't confirmed this results with a fresh installation on baremetal with TC5 netinstall, because lattest grub2 update prevent me installing f19 on another partitition (bootloader installation fails on my system). :(

Any progress to support mate-window-manager?
Remenmber we're running to f20 release.

Nothing was changed on the Initial Setup's side. I have no idea what should be changed.

In former comments you said there was done some changes for metacity in firstboot. Maybe metacity maintainer did also do some changes for metacity.
Can you remember about some changes for this?

No idea, I wasn't the maintainer of firstboot by that time.

I'll retest tomorrow.

(In reply to Vratislav Podzimek from comment #33)
> No idea, I wasn't the maintainer of firstboot by that time.

Is there a way to run initial-setup in debug mode?

*** Bug 1011582 has been marked as a duplicate of this bug. ***

Pls, take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1011582
Here, marco crashed with initial-setup in f20, plus backtrace from abrt.
Maybe this helps you?
PLs notice me if you think the prob is marco.

Initial Setup just runs marco as a window manager, just as it does with other window managers. I have no idea why it could be crashing. :( If you want to debug it somehow, have a look at the /usr/lib/systemd/system/initial-setup-graphical.service file and run the Exec command outside of an X session.

mate-window-manager (marco) crashed with initial-setup.

reporter:       libreport-2.1.7
backtrace_rating: 4
cmdline:        /usr/bin/marco
crash_function: _g_log_abort
executable:     /usr/bin/marco
kernel:         3.11.1-300.fc20.x86_64
package:        mate-window-manager-1.6.2-4.fc20
reason:         Process /usr/bin/marco was killed by signal 6 (SIGABRT)
runlevel:       unknown
type:           CCpp
uid:            0

Created attachment 804042 [details]
environ

Created attachment 804044 [details]
var_log_messages

Created attachment 804045 [details]
backtrace

I'm thinking more and more that it is a problem with marco, but i need more investigation before i re-asigned the report.

I found the issue in mate-window-manager, missing icons as inline pixbuf. 
Upstream commits and new build comming soon.

koji scratch build for testing.
http://koji.fedoraproject.org/koji/taskinfo?taskID=5993108

mate-window-manager-1.6.2-5.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mate-window-manager-1.6.2-5.fc19

mate-window-manager-1.6.2-5.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mate-window-manager-1.6.2-5.fc18

mate-window-manager-1.6.2-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mate-window-manager-1.6.2-5.fc20

Package mate-window-manager-1.6.2-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mate-window-manager-1.6.2-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17892/mate-window-manager-1.6.2-5.fc18
then log in and leave karma (feedback).

mate-window-manager-1.6.2-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

mate-window-manager-1.6.2-5.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

mate-window-manager-1.6.2-5.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.