I can reproduce this reliably as well (it doesn't happen always that cursor is missing in gdm, but in 90% cases it does). Also, I and Frantisek noticed that if you confirm the user and then move the invisible cursor over the password prompt, the cursor is also shown immediately. I.e. the cursor change caused by the text field makes the cursor appear.

Since we don't default to virtio in virt-manager+boxes yet, proposing as a conditional blocker. When using default virtualization stacks, cursor is often missing in gdm, which makes logging in or performing certain actions (like switching a session or enabling accessibility) much more difficult (sometimes the keyboard focus seems broken and you can't reach certain widgets without the mouse).
" A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. "
https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior
"The release must be able host virtual guest instances of the same release. "
https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Self_hosting_virtualization

A workaround is available - switch your VM to virtio-vga GPU (that's harder to do in boxes).

I can reproduce the invisible cursor every boot if the screen resolution is set to something higher than the default 1024x768. The cursor works normally on the gdm login screen, but as soon as the user logs in, the cursor is invisible inside the VM (works fine in the chrome). Upon moving the invisible cursor to Applications and clicking to open any application, the cursor re-appears and works normally until a reboot. If the screen resolution is set to 1024x768, the cursor never goes invisible. I thought this might be related to the need for a vertical scrollbar with the higher resolution, but sizing the window before login to force a scrollbar with 1024x768 still does not produce the invisible cursor.
Host is CentOS 7, VM is F26 running 4.13.9-200.fc26

I'm kinda inclined to -1 blocker on this; it's an inconvenience but I'm not sure it's awful enough to block the release on, especially as it's fairly easy to navigate gdm with the keyboard.

Shane: that sounds like the *opposite* of this bug, as this bug is described as affecting GDM but *not* the logged-in session.

(In reply to Adam Williamson from comment #4)
> Shane: that sounds like the *opposite* of this bug, as this bug is described
> as affecting GDM but *not* the logged-in session.

Sorry, you are correct, I should have read it more thoroughly. I thought it might be related due to the fact that it didn't present until this kernel and some of the discussion in the flicker bug mentioned similar behaviour (i.e. mouse working in the chrome but not in the vm). I think many of the issues I see, though, are due to the host being CentOS which is slower to push the latest virt* stuff. I agree that it is only a minor inconvenience either way.

Shane: it's entirely possible it's related, just wanted to note that you're not both seeing the same symptoms. We really need kernel and/or virt devs to look at this to understand exactly what's going on...

I am -1 to block the F27 on this issue. As Adam already wrote, this is more an inconvenience, and even so there is a workaround.

Discussed during blocker review [1]:

RejectedBlocker AcceptedFreezeException (Final) - we agreed that this doesn't really break things enough to constitute a violation of the criteria, navigating gdm with a keyboard is easy and there are workarounds like using a different video adapter. However, it's visible enough to be worth fixing if the fix is not too complex

[1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-02/

Created attachment 1355944 [details]
i think this should fix it

Created attachment 1355945 [details]
i think this should fix it

(unlike attachment 1355944 [details] this one has the patch)

jforbes did a scratch build here:

 https://koji.fedoraproject.org/koji/taskinfo?taskID=23262863

if someone wants to try it.

eek, hang on it failed.

Created attachment 1356016 [details]
round and round we go

hopefully this one will finish !

https://koji.fedoraproject.org/koji/taskinfo?taskID=23264989

Created attachment 1356077 [details]
getting dizzy

nope, attachment 1356016 [details] didn't finish.

maybe this one will

https://koji.fedoraproject.org/koji/taskinfo?taskID=23266263

Created attachment 1356128 [details]
¯\_(ツ)_/¯

surely it will build this time

https://koji.fedoraproject.org/koji/taskinfo?taskID=23267078

(In reply to Ray Strode [halfline] from comment #15)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=23267078

I see mouse cursor in gdm, seems to work.

kernel-4.13.16-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-92a0ae09aa

kernel-4.13.16-200.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f9f3d80442

kernel-4.13.16-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-92a0ae09aa

kernel-4.13.16-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-92a0ae09aa

kernel-4.13.16-200.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.13.16-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.