This is a tracking bug for Change: Firefox Wayland By Default On Gnome For more details, see: https://fedoraproject.org/wiki/Changes/Firefox_Wayland_By_Default_On_Gnome Firefox is going to run natively on Gnome Wayland session and won't use XWayland/X11 Gtk+ backend by default. The XWayland/X11 Gtk+ backend can be still used via additional firefox-x11 package. This change affects Gnome only and won't be enabled for other Wayland compositors (KDE Plasma, Sway).
Wayland bugs are tracked at Bug 1054334
According to the Fedora 30 schedule[1], today is the deadline for changes to be in a testable state. If your change is ready to be tested, please set the status to MODIFIED. If you know your change will not be ready for Fedora 30, you can set the version to rawhide and notify bcotton. For more information about this milestone, see the Changes Policy[2]. [1] https://fedoraproject.org/wiki/Releases/30/Schedule [2] https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_Completion_deadline
Yes, the default Wayland backend is already there, although there isn't the latest package available due to gcc9 build failures (bah). Also new Firefox 66 with more wayland fixes updates comes to Fedora on 2019-03-19 [1] so the go/no-go decision should be made after FF66 release. [1] https://wiki.mozilla.org/Release_Management/Calendar
For the final decision I'd like to point out a GS bug [1] which affects window screenshots, animations and screencasting of FF on Wayland. I made an attempt to fix that [2][3], but it turned out that bigger changes will be required. That work[4][5] will unfortunately not make it into GS/Mutter 3.32 :( [1] https://gitlab.gnome.org/GNOME/mutter/issues/146 [2] https://gitlab.gnome.org/GNOME/mutter/merge_requests/384 [3] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/341 [4] https://gitlab.gnome.org/GNOME/mutter/merge_requests/409 [5] https://gitlab.gnome.org/GNOME/mutter/tree/gbsneto/content-part2
We have reached the Code Complete (100%) milestone in the Fedora 30 development cycle. At this point, all Changes should be fully code complete and ready for testing during the beta freeze. If your Change has reached this milestone, please set the status to ON_QA. If it has not, this Change will be submitted to FESCo to evaluate the contigency plan and decide if the Change will continue in the Fedora 30 cycle.
The target Firefox version is Firefox 66 here (Fedora 30 has 64 due to recent build failures). According to https://wiki.mozilla.org/Release_Management/Calendar Firefox 66 is going to be released on 2019-03-19 so this will be testable after that.
Proposed as a Freeze Exception for 30-beta by Fedora user sgallagh using the blocker tracking app because: FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. If it does not land in F30 Beta, this Change is Deferred to F31.
Discussed during the 2019-03-11 blocker review meeting: [1] The decision to classify this bug as an "AcceptedFreezeException" was made as, while we are concerned about the gnome-shell issue and the late ff66 release date here, it makes no sense to deny an FE for those reasons, but take the Change post-Beta. So we grant it an FE, but will ask FESCo if it still thinks the change should land in F30 at all given those considerations. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-03-11/f30-blocker-review.2019-03-11-16.04.txt
For the record, it was pointed out that so far as screenshots are confirmed, the bug discussed above affects taking single-window screenshots (alt+print screen) but not a whole desktop screenshot (print screen). This does make it less serious. I'm not sure yet precisely what the impact on screencasting and animations is.
https://pagure.io/fesco/issue/2071#comment-559596
Concerning screencasting: it should only affect window-screencasting, like with screenshots. AFAIK this is new functionality in GS Wayland session (was not available in Fedora 29/GS 3.30), so it's at least not a regression. About animations: from my experience it makes certain animation, e.g. maximizing, a bit glitchy. On the other hand, switching to the Wayland backend makes other things less glitchy (starting FF with accelerated layers). So I'd say it's a trade-off.
First Firefox 66 builds head to koji now. I expect them in testable state later this week.
FESCo voted to defer this Change to F31, so I am removing it from the F30 Beta FE list (it only gets an F30 Beta FE if it's an F30 Change, obviously).
The change is reverted for Fedora 30 in the firefox 66.0 update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-38ec450c27
There's a new update for that: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2e62c6961a
Um. Wait. Are you saying that the Firefox in F30 stable *right now* is Wayland-native? So if we want to have X11-native Firefox for Beta we have to pull in that update?
To be clear, I was previously reading your comment #6 as saying that Wayland-native Firefox was not going to be enabled for F30 until that Firefox 66 release landed.
(In reply to Adam Williamson from comment #16) > Um. Wait. Are you saying that the Firefox in F30 stable *right now* is > Wayland-native? So if we want to have X11-native Firefox for Beta we have to > pull in that update? Yes, that correct. The update is here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2e62c6961a Also new firefox 66.0.1 with security updates from Pwn2Own is coming out on Monday. (In reply to Adam Williamson from comment #17) > To be clear, I was previously reading your comment #6 as saying that > Wayland-native Firefox was not going to be enabled for F30 until that > Firefox 66 release landed. I was meaning in comment #6 that the Firefox 66 build will have all important Wayland fixes and will be ready for testing/final decision. The default Wayland backend has been enabled on Firefox / F30 since this bug was created.
Btw. also see comment 3 where I stated the default Wayland is already there and switched the bug to modified.
Ah. OK. In that case we'll need an FE bug. I'll file one...
https://bugzilla.redhat.com/show_bug.cgi?id=1691852 filed. So you think we should wait till Monday and pull in the new pwn2own fixes for Beta?
(In reply to Adam Williamson from comment #21) > https://bugzilla.redhat.com/show_bug.cgi?id=1691852 filed. So you think we > should wait till Monday and pull in the new pwn2own fixes for Beta? Yes, I'm submitting the builds now.
Uh...but what do you mean about Monday, then? :) If the builds you're submitting right now have the fixes, they should be done later today and we can pull them into a compose tonight or tomorrow...
(In reply to Adam Williamson from comment #23) > Uh...but what do you mean about Monday, then? :) If the builds you're > submitting right now have the fixes, they should be done later today and we > can pull them into a compose tonight or tomorrow... Sure, grab them when they're ready, it's firefox-66.0.1-1.
OK, so the build should complete in about 8 hours, we will go ahead and pull it into a new compose at that point. Thanks.
Fixed in Rawhide.