RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1025444 - Workspace switching- shortcuts active during gnome-initial-setup
Summary: Workspace switching- shortcuts active during gnome-initial-setup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-31 17:48 UTC by Bill Nottingham
Modified: 2015-11-19 07:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1024487
Environment:
Last Closed: 2015-11-19 07:12:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2216 0 normal SHIPPED_LIVE gnome compositor stack bug fix and enhancement update 2015-11-19 08:26:34 UTC

Description Bill Nottingham 2013-10-31 17:48:10 UTC 
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
Comment 2 Matthias Clasen 2013-10-31 18:35:18 UTC 
this was fixed upstream in gnome-shell here:

https://bugzilla.gnome.org/show_bug.cgi?id=698593
Comment 4 Michael Boisvert 2014-01-27 21:59:54 UTC 
I am still able to switch workspaces using ctrl+alt+arrow key during initial setup of RHEL-7.0-20140122.0.
Comment 5 Florian Müllner 2014-02-13 17:59:19 UTC 
(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?
Comment 6 Michael Boisvert 2014-02-24 19:13:23 UTC 
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.
Comment 8 Tomas Pelka 2014-04-08 07:41:59 UTC 
(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?
Comment 9 Michael Boisvert 2014-04-09 13:12:37 UTC 
(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.
Comment 12 Florian Müllner 2014-04-10 13:59:37 UTC 
(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.
Comment 14 Michal Domonkos 2015-05-14 09:10:36 UTC 
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.
Comment 18 errata-xmlrpc 2015-11-19 07:12:02 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.