2016-09-23 23:03:13 +00:00
|
|
|
use base "installedtest";
|
|
|
|
use strict;
|
|
|
|
use testapi;
|
2017-01-18 07:15:44 +00:00
|
|
|
use utils;
|
2016-09-23 23:03:13 +00:00
|
|
|
use packagetest;
|
|
|
|
|
|
|
|
# This test sort of covers QA:Testcase_desktop_update_notification
|
|
|
|
# and QA:Testcase_desktop_error_checks . If it fails, probably *one*
|
|
|
|
# of those failed, but we don't know which (deciphering which is
|
|
|
|
# tricky and involves likely-fragile needles to try and figure out
|
|
|
|
# what notifications we have).
|
|
|
|
|
2024-09-26 08:54:16 +00:00
|
|
|
sub create_user_i3_config {
|
|
|
|
my %args = @_;
|
|
|
|
my $login = $args{login};
|
|
|
|
|
|
|
|
assert_script_run("mkdir -p /home/$login/.config/i3/");
|
|
|
|
# ensure that no alias of cp prevents an existing config from being overwritten
|
|
|
|
assert_script_run("/usr/bin/cp -f /etc/i3/config /home/$login/.config/i3/config");
|
|
|
|
assert_script_run("sed -i '/i3-config-wizard/d' /home/$login/.config/i3/config");
|
|
|
|
assert_script_run "chown -R $login:$login /home/$login/.config";
|
|
|
|
assert_script_run "restorecon -vr /home/$login/.config";
|
|
|
|
}
|
|
|
|
|
2016-09-23 23:03:13 +00:00
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
my $desktop = get_var("DESKTOP");
|
2023-08-23 16:47:03 +00:00
|
|
|
my $relnum = get_release_number;
|
2016-09-23 23:03:13 +00:00
|
|
|
# for the live image case, handle bootloader here
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
2022-07-28 20:32:57 +00:00
|
|
|
do_bootloader(postinstall => 1, params => '3');
|
2016-09-23 23:03:13 +00:00
|
|
|
}
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
else {
|
2022-07-28 20:32:57 +00:00
|
|
|
do_bootloader(postinstall => 0, params => '3');
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
}
|
|
|
|
boot_to_login_screen;
|
2022-12-13 18:38:29 +00:00
|
|
|
# tty1 is used here for historic reasons, but it's not hurting
|
|
|
|
# anything and changing it might, so let's leave it...
|
2022-07-28 20:32:57 +00:00
|
|
|
$self->root_console(tty => 1);
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
# ensure we actually have some package updates available
|
2016-09-23 23:03:13 +00:00
|
|
|
prepare_test_packages;
|
2020-10-17 22:22:09 +00:00
|
|
|
my $user = get_var('USER_LOGIN', 'test');
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if ($desktop eq 'gnome') {
|
|
|
|
# On GNOME, move the clock forward if needed, because it won't
|
|
|
|
# check for updates before 6am(!)
|
|
|
|
my $hour = script_output 'date +%H';
|
|
|
|
if ($hour < 6) {
|
|
|
|
script_run 'systemctl stop chronyd.service ntpd.service';
|
|
|
|
script_run 'systemctl disable chronyd.service ntpd.service';
|
|
|
|
script_run 'systemctl mask chronyd.service ntpd.service';
|
|
|
|
assert_script_run 'date --set="06:00:00"';
|
|
|
|
}
|
|
|
|
if (get_var("BOOTFROM")) {
|
2021-03-06 01:56:56 +00:00
|
|
|
# Set a bunch of update checking-related timestamps to
|
|
|
|
# two days ago or two weeks ago to try and make sure we
|
|
|
|
# get notifications, see:
|
|
|
|
# https://wiki.gnome.org/Design/Apps/Software/Updates#Tentative_Design
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
my $now = script_output 'date +%s';
|
2022-07-28 20:32:57 +00:00
|
|
|
my $yyday = $now - 2 * 24 * 60 * 60;
|
|
|
|
my $longago = $now - 14 * 24 * 60 * 60;
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
# have to log in as the user to do this
|
|
|
|
script_run 'exit', 0;
|
2024-06-20 13:39:34 +00:00
|
|
|
console_login(user => $user, password => get_var('USER_PASSWORD', 'weakpassword'));
|
2021-03-06 01:56:56 +00:00
|
|
|
script_run "gsettings set org.gnome.software check-timestamp ${yyday}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software update-notification-timestamp ${longago}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software online-updates-timestamp ${longago}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software upgrade-notification-timestamp ${longago}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software install-timestamp ${longago}", 0;
|
|
|
|
wait_still_screen 5;
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
script_run 'exit', 0;
|
2022-07-28 20:32:57 +00:00
|
|
|
console_login(user => 'root', password => get_var('ROOT_PASSWORD', 'weakpassword'));
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
}
|
2024-06-20 13:39:34 +00:00
|
|
|
}
|
|
|
|
elsif ($desktop eq 'i3') {
|
2020-10-17 22:22:09 +00:00
|
|
|
assert_script_run('dnf install -y libnotify');
|
2024-06-20 13:39:34 +00:00
|
|
|
unless (get_var("BOOTFROM")) {
|
|
|
|
$user = "liveuser";
|
2020-10-17 22:22:09 +00:00
|
|
|
}
|
2024-06-20 13:39:34 +00:00
|
|
|
assert_script_run("usermod -a -G dialout $user");
|
|
|
|
create_user_i3_config(login => $user);
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
}
|
2023-03-28 00:35:22 +00:00
|
|
|
if ($desktop eq 'kde' && get_var("BOOTFROM")) {
|
|
|
|
# need to login as user for this
|
|
|
|
script_run 'exit', 0;
|
|
|
|
console_login(user => get_var('USER_LOGIN', 'test'), password => get_var('USER_PASSWORD', 'weakpassword'));
|
|
|
|
# unset the 'last time notification was shown' setting in case
|
|
|
|
# it got shown during install_default_upload:
|
|
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=2178311
|
|
|
|
script_run 'kwriteconfig5 --file PlasmaDiscoverUpdates --group Global --key LastNotificationTime --delete', 0;
|
|
|
|
wait_still_screen 5;
|
|
|
|
script_run 'exit', 0;
|
|
|
|
console_login(user => 'root', password => get_var('ROOT_PASSWORD', 'weakpassword'));
|
|
|
|
}
|
|
|
|
|
2020-04-14 19:10:02 +00:00
|
|
|
# can't use assert_script_run here as long as we're on tty1
|
2023-02-09 22:56:33 +00:00
|
|
|
# we don't use isolate per:
|
|
|
|
# https://github.com/systemd/systemd/issues/26364#issuecomment-1424900066
|
|
|
|
type_string "systemctl start graphical.target\n";
|
2018-10-13 04:16:33 +00:00
|
|
|
# we trust systemd to switch us to the right tty here
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
2024-09-26 15:57:27 +00:00
|
|
|
my $password = get_var("USER_PASSWORD", "weakpassword");
|
2021-09-03 23:56:17 +00:00
|
|
|
assert_screen 'graphical_login', 60;
|
2020-11-12 18:16:03 +00:00
|
|
|
wait_still_screen 10, 30;
|
2024-09-26 15:57:27 +00:00
|
|
|
dm_perform_login($desktop, $password);
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
}
|
2022-07-28 20:32:57 +00:00
|
|
|
check_desktop(timeout => 90);
|
2022-05-16 22:52:07 +00:00
|
|
|
# now, WE WAIT. this is just an unconditional wait - rather than
|
|
|
|
# breaking if we see an update notification appear - so we catch
|
|
|
|
# things that crash a few minutes after startup, etc.
|
2022-07-28 20:32:57 +00:00
|
|
|
for my $n (1 .. 16) {
|
2022-05-16 22:52:07 +00:00
|
|
|
sleep 30;
|
|
|
|
mouse_set 10, 10;
|
2020-08-07 01:03:08 +00:00
|
|
|
send_key "spc";
|
2016-09-23 23:03:13 +00:00
|
|
|
mouse_hide;
|
|
|
|
}
|
|
|
|
if ($desktop eq 'gnome') {
|
2020-10-14 22:31:59 +00:00
|
|
|
# click the clock to show notifications. of course, we have no
|
|
|
|
# idea what'll be in the clock, so we just have to click where
|
|
|
|
# we know it is
|
2016-09-23 23:03:13 +00:00
|
|
|
mouse_set 512, 10;
|
|
|
|
mouse_click;
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
if ($desktop eq 'kde') {
|
2019-05-31 00:03:58 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
2020-10-14 22:31:59 +00:00
|
|
|
# first check the systray update notification is there
|
|
|
|
assert_screen "desktop_update_notification_systray";
|
2019-05-31 00:03:58 +00:00
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
# now open the notifications view in the systray
|
|
|
|
if (check_screen 'desktop_icon_notifications') {
|
|
|
|
# this is the little bell thing KDE sometimes shows if
|
|
|
|
# there's been a notification recently...
|
2019-10-30 16:02:20 +00:00
|
|
|
click_lastmatch;
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
else {
|
|
|
|
# ...otherwise you have to expand the systray and click
|
|
|
|
# "Notifications"
|
|
|
|
assert_and_click 'desktop_expand_systray';
|
|
|
|
assert_and_click 'desktop_systray_notifications';
|
|
|
|
}
|
2024-06-21 15:40:36 +00:00
|
|
|
# In F32+ we may get an 'akonadi did something' message
|
|
|
|
if (check_screen 'akonadi_migration_notification', 5) {
|
|
|
|
click_lastmatch;
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
}
|
2020-10-17 22:22:09 +00:00
|
|
|
if ($desktop eq 'i3') {
|
|
|
|
# we launch a terminal so that the top of the screen is filled with
|
|
|
|
# something that we know and can check that it is not covered by a
|
|
|
|
# notification popup from dunst
|
2024-06-20 13:39:34 +00:00
|
|
|
send_key('alt-ret');
|
2020-10-17 22:22:09 +00:00
|
|
|
assert_screen("apps_run_terminal");
|
2024-06-20 13:39:34 +00:00
|
|
|
assert_script_run('notify-send -t 10000 "foo"');
|
2020-10-17 22:22:09 +00:00
|
|
|
assert_screen("i3_dunst_foo_notification", timeout => 5);
|
|
|
|
|
2024-06-20 13:39:34 +00:00
|
|
|
sleep 11;
|
|
|
|
if (check_screen("i3_dunst_foo_notification")) {
|
|
|
|
# The notifications should not be shown any more.
|
|
|
|
record_soft_fail("i3 shows notifications longer than expected");
|
|
|
|
}
|
2020-10-17 22:22:09 +00:00
|
|
|
return;
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
2022-05-16 22:52:07 +00:00
|
|
|
# we should see an update notification and no others
|
|
|
|
assert_screen "desktop_update_notification_only";
|
2020-10-14 22:31:59 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
# for the live case there should be *no* notifications
|
2016-09-23 23:03:13 +00:00
|
|
|
assert_screen "desktop_no_notifications";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
2022-07-28 20:32:57 +00:00
|
|
|
return {fatal => 1};
|
2016-09-23 23:03:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|