Hide Forgot
The keynavs for switching workspaces works during initial setup. They probably shouldn't be enabled - they serve no useful function there. Version-Release number of selected component (if applicable): 20131029 nightly
this was fixed upstream in gnome-shell here: https://bugzilla.gnome.org/show_bug.cgi?id=698593
I am still able to switch workspaces using ctrl+alt+arrow key during initial setup of RHEL-7.0-20140122.0.
(In reply to Michael Boisvert from comment #4) > I am still able to switch workspaces using ctrl+alt+arrow key during initial > setup of RHEL-7.0-20140122.0. Mmh, I've just tested this with a new VM install and the shortcuts are disabled as expected. However there are two ways initial setup is run: 1. if a non-root user has been created during installation, gnome-initial-setup is run in the user session on first login to assist with setting up the basics 2. if no non-root user has been created during installation, gnome-initial-setup is run in a special mode to create a user and assist with setting up the basics In the first case we have a normal session including workspaces / activity overview, so all shortcuts are expected to work normally. It's only in the second case that shortcuts should be disabled. Maybe your observation is about the first case?
I started a clean installation of the latest non-nightly build of RHEL7.0 and I used the second scenario. I did not create a non-root user during the main installation. After the machine restarted, the initial setup began and I could change the workspace to 1, 2, 3 and 4. 2 - 4 were blank black screens. I could change the workspaces during the License Agreement, Kdump and Subscription Management screens as well.
(In reply to Michael Boisvert from comment #6) > I started a clean installation of the latest non-nightly build of RHEL7.0 > and I used the second scenario. I did not create a non-root user during the > main installation. After the machine restarted, the initial setup began and > I could change the workspace to 1, 2, 3 and 4. 2 - 4 were blank black > screens. > > I could change the workspaces during the License Agreement, Kdump and > Subscription Management screens as well. So Mike can ve move to VERIFIED?
(In reply to Tomas Pelka from comment #8) > (In reply to Michael Boisvert from comment #6) > > I started a clean installation of the latest non-nightly build of RHEL7.0 > > and I used the second scenario. I did not create a non-root user during the > > main installation. After the machine restarted, the initial setup began and > > I could change the workspace to 1, 2, 3 and 4. 2 - 4 were blank black > > screens. > > > > I could change the workspaces during the License Agreement, Kdump and > > Subscription Management screens as well. > > So Mike can ve move to VERIFIED? I don't think so. The workspace switching should be disabled during the Initial Setup, and I am still seeing them there.
(In reply to Michael Boisvert from comment #9) > I don't think so. The workspace switching should be disabled during the > Initial Setup, and I am still seeing them there. Can you please provide exact steps to reproduce this issue? As of comment #5, in my testing neither <ctrl><alt>up/down nor <super>PgUp/PgDown switched workspaces for me during initial setup.
I can confirm the initial setup behaviour in GNOME-3.14 being exactly as described in comment 5. If no user was created during installation, the initial setup will run in a restricted gnome session, meaning the workspace shortcuts will be disabled. Fix in GNOME-3.14, moving to MODIFIED for now.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2216.html