Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix UI build bar alignment broken on index page #3563

Merged
merged 1 commit into from Nov 26, 2020

Conversation

ilausuch
Copy link
Contributor

@ilausuch ilausuch commented Nov 17, 2020

Problem: The right side of some build bars of is
misaligned when the screen is less wide than 880
pixels. This occurs because some bars have more
text than others and this text forces a minimum size.

Solution: a minimum size is set for all bars to
ensure the maximum possible text size.

https://progress.opensuse.org/issues/77929

image

@Martchus
Copy link
Contributor

The test failure might actually be relevant:

[12:57:47] t/ui/16-tests_job_next_previous.t ...... 45/? Bailout called.  Further testing stopped:  clickElement: element click intercepted: Element <a href="/tests/99928">...</a> is not clickable at point (355, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
FAILED--Further testing stopped: clickElement: element click intercepted: Element <a href="/tests/99928">...</a> is not clickable at point (355, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101

Maybe it becomes clear why this happens when running it non-headless locally.

I'm also wondering how you (and @okurz who created the ticket) do actually reproduce the issue. Locally and on o3 the index page looks just fine.

@ilausuch
Copy link
Contributor Author

I'm also wondering how you (and @okurz who created the ticket) do actually reproduce the issue. Locally and on o3 the index page looks just fine.

In the index page, you can resize the screen until the alignment is broken. More or less at 880 px if you has a build with 5 different sections (colors)

@ilausuch
Copy link
Contributor Author

The test failure might actually be relevant:

[12:57:47] t/ui/16-tests_job_next_previous.t ...... 45/? Bailout called.  Further testing stopped:  clickElement: element click intercepted: Element <a href="/tests/99928">...</a> is not clickable at point (355, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
FAILED--Further testing stopped: clickElement: element click intercepted: Element <a href="/tests/99928">...</a> is not clickable at point (355, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101

Maybe it becomes clear why this happens when running it non-headless locally.

I don't think is directly related, is it?

@okurz
Copy link
Member

okurz commented Nov 17, 2020

if you think the issue is not related then look if you find a corresponding ticket. But I can tell you already: There is none. So, yeah, you need to look into this before we want to merge the PR :)

@Martchus
Copy link
Contributor

Ah, ok - so you really need to make the window small and have more sections. After a closer look the change doesn't look related. I've just assumed it might be because changing the size of elements sometimes affects the visibility and therefore elements might not be clickable anymore. I've re-triggered the CI run.

Copy link
Member

@okurz okurz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 I don't know if it's possible to rely less on absolute measures but I also don't know a better alternative that would work for sure. Would be nice if you could provide a screenshot showing that it works.

@Martchus
Copy link
Contributor

The failing tests are definitely unrelated (tested locally).

@Martchus
Copy link
Contributor

Although it is still not perfect, e.g.

screenshot_20201118_125713

@okurz
Copy link
Member

okurz commented Nov 18, 2020

If you think the failing UI tests are unrelated I would still not merge this PR until these failures are being addressed. As you should know we invest great care to have our tests stable and there are many things that could be done, e.g. report ticket, move to unstable tests, fix it while working on this PR, etc.

@kalikiana
Copy link
Member

kalikiana commented Nov 18, 2020

Just in case logs disappear in the meanwhile, these are the failures I see on CircleCI right now, and which should be provided if one or more tickets are filed once poo becomes available again - interestingly enough I can't spot these anywhere else at the moment, be it master or other PRs:

RETRY=3 timeout -s SIGINT -k 5 -v $((5 * (3 + 1) ))m tools/retry prove -l --harness TAP::Harness::JUnit --timer t/ui/26-jobs_restart.t
Retry 1 of 3 …
[14:09:07] t/ui/26-jobs_restart.t .. 7/? Bailout called.  Further testing stopped:  clickElement: element click intercepted: Element <a class="cancel" href="/api/v1/jobs/99988/cancel">...</a> is not clickable at point (359, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
FAILED--Further testing stopped: clickElement: element click intercepted: Element <a class="cancel" href="/api/v1/jobs/99988/cancel">...</a> is not clickable at point (359, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
Retry 2 of 3 …
[14:09:32] t/ui/26-jobs_restart.t .. 7/? Bailout called.  Further testing stopped:  clickElement: element click intercepted: Element <a class="cancel" href="/api/v1/jobs/99988/cancel">...</a> is not clickable at point (359, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
FAILED--Further testing stopped: clickElement: element click intercepted: Element <a class="cancel" href="/api/v1/jobs/99988/cancel">...</a> is not clickable at point (359, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
Retry 3 of 3 …
[14:09:57] t/ui/26-jobs_restart.t .. 7/? Bailout called.  Further testing stopped:  clickElement: element click intercepted: Element <a class="cancel" href="/api/v1/jobs/99988/cancel">...</a> is not clickable at point (359, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
FAILED--Further testing stopped: clickElement: element click intercepted: Element <a class="cancel" href="/api/v1/jobs/99988/cancel">...</a> is not clickable at point (359, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
make[2]: *** [Makefile:171: test-unit-and-integration] Error 1
make[2]: Leaving directory '/home/squamata/project'
make[1]: *** [Makefile:166: test-with-database] Error 2
make[1]: Leaving directory '/home/squamata/project'
make: *** [Makefile:147: test-unstable] Error 2

and

RETRY=0 timeout -s SIGINT -k 5 -v $((25 * (0 + 1) ))m tools/retry prove -l --harness TAP::Harness::JUnit --timer t/ui/*.t
[14:05:42] t/ui/02-csrf.t ......................... ok    10449 ms ( 0.02 usr  0.01 sys +  9.21 cusr  0.96 csys = 10.20 CPU)
[14:05:52] t/ui/02-list-group.t ................... ok    19645 ms ( 0.02 usr  0.00 sys + 14.32 cusr  1.23 csys = 15.57 CPU)
[14:06:12] t/ui/03-source.t ....................... ok     7858 ms ( 0.01 usr  0.00 sys +  6.91 cusr  0.66 csys =  7.58 CPU)
[14:06:20] t/ui/04-api_keys.t ..................... ok     7467 ms ( 0.04 usr  0.00 sys +  6.51 cusr  0.78 csys =  7.33 CPU)
[14:06:27] t/ui/05-auth.t ......................... ok     7574 ms ( 0.04 usr  0.00 sys +  6.53 cusr  0.92 csys =  7.49 CPU)
[14:06:35] t/ui/06-operator_links.t ............... ok    23238 ms ( 0.04 usr  0.00 sys + 12.19 cusr  1.35 csys = 13.58 CPU)
[14:06:58] t/ui/07-file.t ......................... ok    10167 ms ( 0.04 usr  0.00 sys +  8.50 cusr  0.88 csys =  9.42 CPU)
[14:07:08] t/ui/09-admin_creation.t ............... ok     6705 ms ( 0.01 usr  0.00 sys +  5.92 cusr  0.51 csys =  6.44 CPU)
[14:07:15] t/ui/09-users-list.t ................... ok     7129 ms ( 0.03 usr  0.01 sys +  6.24 cusr  0.46 csys =  6.74 CPU)
[14:07:22] t/ui/10-tests_overview.t ............... ok    23878 ms ( 0.12 usr  0.00 sys + 15.27 cusr  1.11 csys = 16.50 CPU)
[14:07:46] t/ui/12-needle-edit.t .................. ok    54427 ms ( 0.15 usr  0.01 sys + 118.40 cusr 12.71 csys = 131.27 CPU)
[14:08:41] t/ui/13-admin-no-login.t ............... ok    16418 ms ( 0.03 usr  0.00 sys + 11.48 cusr  0.84 csys = 12.35 CPU)
[14:08:57] t/ui/13-admin.t ........................ ok    38506 ms ( 0.16 usr  0.00 sys + 17.91 cusr  1.06 csys = 19.13 CPU)
[14:09:36] t/ui/14-dashboard-parents.t ............ ok    26803 ms ( 0.06 usr  0.00 sys + 14.69 cusr  1.09 csys = 15.84 CPU)
[14:10:02] t/ui/14-dashboard.t .................... ok    29733 ms ( 0.08 usr  0.00 sys + 14.49 cusr  0.90 csys = 15.47 CPU)
[14:10:32] t/ui/15-admin-workers.t ................ 6/? 
    #   Failed test 'on 99963'
    #   at t/ui/15-admin-workers.t line 128.
    #                   ''
    #     doesn't match '(?^:Worker status\nJob: 99963)'
    # Looks like you failed 1 test of 22.
[14:10:32] t/ui/15-admin-workers.t ................ 7/? 
#   Failed test 'worker overview'
#   at t/ui/15-admin-workers.t line 151.
[14:10:32] t/ui/15-admin-workers.t ................ 8/? [14:10:32] t/ui/15-admin-workers.t ................ 16/? [14:10:32] t/ui/15-admin-workers.t ................ 19/? # Looks like you failed 1 test of 19.
                                                          [14:10:32] t/ui/15-admin-workers.t ................ Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/19 subtests 
[14:10:57] t/ui/15-comments.t ..................... ok    47129 ms ( 0.32 usr  0.03 sys + 24.52 cusr  1.24 csys = 26.11 CPU)
[14:11:44] t/ui/15-search.t ....................... ok    17711 ms ( 0.01 usr  0.00 sys + 13.87 cusr  1.20 csys = 15.08 CPU)
[14:12:02] t/ui/16-activity-view.t ................ ok    17140 ms ( 0.03 usr  0.00 sys + 13.18 cusr  1.08 csys = 14.29 CPU)
[14:12:19] t/ui/16-tests_dependencies.t ........... ok    23660 ms ( 0.04 usr  0.00 sys + 15.32 cusr  1.03 csys = 16.39 CPU)
[14:12:43] t/ui/16-tests_job_next_previous.t ...... 52/? Bailout called.  Further testing stopped:  clickElement: element click intercepted: Element <a href="/tests/99928">...</a> is not clickable at point (355, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
FAILED--Further testing stopped: clickElement: element click intercepted: Element <a href="/tests/99928">...</a> is not clickable at point (355, 598). Other element would receive the click: <td class=" test">...</td> at /home/squamata/project/t/ui/../lib/OpenQA/SeleniumTest.pm:101
make[2]: *** [Makefile:171: test-unit-and-integration] Error 255
make[2]: Leaving directory '/home/squamata/project'
make[1]: *** [Makefile:166: test-with-database] Error 2

@Martchus
Copy link
Contributor

interestingly enough I can't spot these anywhere else at the moment, be it master or other PRs

I saw it so far also only here.

I gave t/ui/16-tests_job_next_previous.t another local run in non-headless mode because I was curious what this other element which would receive the click is. It is really just the surrounding table cell. There's nothing suspicious going on. However, when I ran it in headless mode, I've got the following:

ok 52 - Wait for jQuery successful: wait for All Tests displayed before looking for 99928
Bailout called.  Further testing stopped:  clickElement: element not interactable: element has zero size at /hdd/openqa-devel/repos/openQA/t/ui/../lib/OpenQA/SeleniumTest.pm:101

And I this error actually every time with the only workaround being the non-headless mode.

When I do a screenshot in headless mode I get this:

img1

Unfortunately it misses the interesting part because the link in question is within the scheduled table.

@Martchus
Copy link
Contributor

Martchus commented Nov 18, 2020

When I try to use $driver->capture_screenshot('/hdd/img3.png', {'full' => 1}); to make a full screenshot I get Full page screenshot only supported on geckodriver at t/ui/16-tests_job_next_previous.t line 210.. I thought I was using chromedriver here. By the way, considering the $driver->capture_screenshot function (which works in non-full mode) I think we can really drop our own make_screenshot helper (as @okurz already did in one PR).

Unfortunately $driver->mouse_move_to_location(element => $driver->find_element('[href="/tests/99928"]')); doesn't work either.

Copy link
Contributor

@Martchus Martchus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I've did another check against master and it works. So the test failure is locally reproducible but only in non-headless mode and at least on my system the error message is only similar but not identical to the one from the CI job.

The screenshot from my previous comment actually shows the problem: The progress bar is unusually wide. That's because the CSS rule you've added here is wrongly applied to progress bars on the 'All tests' page (and possibly other pages). You can see that using the developer tools. It isn't 100 % clear to me why this leads to the test failure (it actually tries to click a link in the scheduled jobs table below). However, this nevertheless clearly shows an error. I guess if you ensure that the rule is only applied to the progress bars on the actual dashboard the test error will go away as well.

@ilausuch
Copy link
Contributor Author

It isn't 100 % clear to me why this leads to the test failure (it actually tries to click a link in the scheduled jobs table below). However, this nevertheless clearly shows an error. I guess if you ensure that the rule is only applied to the progress bars on the actual dashboard the test error will go away as well.

Thanks for the investigation. I am trying an new idea. however I am getting the same problem with t/ui/16-tests_job_next_previous.t with and without the patch but is a test exceeds runtime limit of '20' seconds

Problem: The right side of some build bars of is
misaligned when the screen is less wide than 880
pixels. This occurs because some bars have more
text than others and this text forces a minimum size.

Solution: a minimum size is set for all bars to
ensure the maximum possible text size.

https://progress.opensuse.org/issues/77929
@ilausuch
Copy link
Contributor Author

I think this new commit solves the problems and only affects to the index page (I think nothing else). Also, I ran the test and was ok.

@okurz
Copy link
Member

okurz commented Nov 25, 2020

the test failed in "scheduler". This looks like a known issue (and we have that recorded in tickets) but now it fails. We could simply bump the retry limit relating to these tickets or a new one. But I suggest to not just retrigger and accept the flakyness as given.

@ilausuch
Copy link
Contributor Author

Ok, It passes now :)

@okurz
Copy link
Member

okurz commented Nov 26, 2020

huh, who clicked the retrigger button in circleCI?

Copy link
Member

@kalikiana kalikiana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At last it does work, I was reading "it should pass" earlier but it didn't... @ilausuch what was the actual issue in the end? Something to keep in mind for future CSS or test code?

@mergify mergify bot merged commit 26b9814 into master Nov 26, 2020
@Martchus Martchus deleted the fix_ui_build_bar_aligment branch November 26, 2020 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants