Proposing as a Final freeze exception; we can't fix this for the live environment with an update, and it's a super annoying bug (and can even cause you to lose significant content if you hit it when cutting from an app which doesn't have an Undo feature that will undo a cut).

+1 FE

From sgallagh, per conversation on #fedora-qa:

+1 FE

+1 FE

That's +4 (counting me), setting accepted. I'm a bit worried about poking GTK+ this late, but the bug *is* pretty annoying...

FEDORA-2019-18a505f5ab has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-18a505f5ab

FEDORA-2019-18a505f5ab has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-18a505f5ab

For the record, the first attempt to fix this introduced another bug that was if anything worse, so we're not including it in the candidate compose that's building ATM. A fix for *that* bug showed up shortly after we started it, and is in gtk3-3.24.12-3.fc31, which I just edited into the update.

so I tried to sneak this into the RC without bothering anyone too much about it, but that kinda failed. As mentioned in #c8, we've now got an RC spinning without this fixed.

Given that...I think we ought to at least *consider* it as a blocker under the 'basic functionality' criterion for all apps in Workstation, treating copy/cut/paste as 'basic functionality' of just about every app (try working without it for ten minutes and see how that goes). I think it's at least worth considering. If we ship F31 without fixing this, then occasionally-not-working copy/cut is baked into the live image forever. Also there's one specifically annoying case of this: if you *cut* and hit the bug, in an app which doesn't have an undo function, you lose the text you cut. (This has happened to me more than once with hexchat).

On the other hand - it's not a complete showstopper or anything, and I kinda knew about this for months but didn't report it until yesterday, so you could argue it for waiving as a 'late blocker' too.

I'll ask folks on IRC to take a look at this and vote on it.

practical consequence of taking this as a blocker would be: we'd cancel the running RC and fire a new one with the second attempt to fix the bug in it. That would cost us a few hours, as that's how long the running RC has been running for. If the second fix still turns out to have problems, we'd then be late enough that we'd probably be looking at a slip.

I'm -1 to block on this. It's a late blocker and while it's ugly and will annoy people, it's fixable with a post-release update. Yes, it'll be present on the Live media, which is unfortunate. I think that if this was the last blocker being considered at a Go/No-Go meeting, we wouldn't slip for this. Particularly since last I heard, the fix we thought we had caused other problems and there's no clear ETA on a "correct" fix.

(In reply to Adam Williamson from comment #10)
> practical consequence of taking this as a blocker would be: we'd cancel the
> running RC and fire a new one with the second attempt to fix the bug in it.
> That would cost us a few hours, as that's how long the running RC has been
> running for. If the second fix still turns out to have problems, we'd then
> be late enough that we'd probably be looking at a slip.

I suggest that we let the current RC complete and fire another one with the proposed fix immediately thereafter. We can decide at Go/No-Go which one to ship.

by policy we can't fire a new RC just to fix an FE, though. we have broken this policy I think once before, but I kinda would feel sucky about doing it now and asking people to test two RCs almost simultaneously on very short notice. it *is* a choice, though.

also the second one would be getting pretty short on testing time, by the time the first one has finished.

Well, now the compose failed, so we could pull it in as a FE?

Yeah, were doing that, so blocker status becomes less important again.

In case it's not already solved, I vote +1 blocker under basic functionality criterion.

So far anyway it seems to be working and nothing else has broken - it'd be good if you and the other testers can keep an eye out for this while testing.

gtk3-3.24.12-3.fc31 has been pushed to the Fedora 31 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-2019-18a505f5ab

gtk3-3.24.12-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.