1.Заходим на страницу пользователя.
2. В поиске пишим группу, её находит, чек боксы пусты. Примерно 10 штук
3. Отмечаем чек боксы, т.е ставим галочку в них.
4. Сохраняем изменения.

$(".icheckbox_square-green"). click(1) ;
$(".icheckbox_square-green"). click(2) ;
И так до 10 это не удобно.

Все кликается тупо по одному, нету гнопок all check.

Ну вот, уже нашли баг в UX))

Если вы про кнопку all check, то это такая система, её там быть не должно.

Ну вам даже автоматически кликать "неудобно", а пользователю то как...

Всем привет!

Заметил странную деталь при использовании контейнеров.
Есть элемент, который долго грузится на странице. Ставим явное ожидание:

element.waitUntil(visible, 60_000);

Нюанс в том, что элемент лежит в контейнере:

container = $(someContainerLocator)
element = container.$(someElementLocator);

Элемент появляется на странице тогда, когда появляется и его контейнер (что вполне нормально).
При этом Selenide падает на строчке с ожиданием element с таким исключением:

Element not found {someContainerLocator}
Expected: exist
Timeout: 60 s.

Приходится делать последовательно -- сначала ждем видимости контейнера, потом элемента внутри него (тогда все проходит!):

container.waitUntil(visible, 60_000);
element.waitUntil(visible, 60_000); // строго говоря, тут 60 секунд уже ждать необязательно

Selenide ver. 5.13.1

Я таки думаю, что контейнер реально не успевает отрисоваться за 60 секунд. Тут никакой мистики.

успевает. Поэтому обходной вариант работает (когда ждем контейнер сначала)

тут странно как раз то, что если ждать сразу элемент без контейнера (element.waitUntil(visible, 60_000)), то он сначала ждет контейнер 4 секунды, и падает. Хотя должен ждать 60 секунд всю конструкцию вместе.

Ах, ну да. Кажется, он действительно ждёт 4 секунды контейнер и 60 секунд сам элемент.

это баг или фича?  🙂
просто у нас много всего на таких контейнерах построено, и приходится всегда сначала их дожидаться, прежде чем с элементами внутри работать... (когда элементы долго грузятся)

по мне так логично что should и wait должны все таки дожидаться всю цепочку за одинаковое время (самое долгое из указанных)

А хз. Я об этом просто не думал.

не понял, а почему он падает?

Повторюсь. Потому что если написать весь wait явно, то будет так:

$(containerLocator).$(elementLocator).waitUntil(visible, 60_000);

В итоге вместо того, чтобы все элементы ждать 60 секунд, Selenide ждёт контейнер 4 секунды (и падает), а после (если не упадёт) будет ждать элемент 60 секунд.

А падает потому что ни контейнер, ни элемент не успевают за 4 секунды загрузиться.

> В итоге вместо того, чтобы все элементы ждать 60 секунд, Selenide ждёт контейнер 4 секунды (и падает), а после (если не упадёт) будет ждать элемент 60 секунд.

забавно, кажется так не планировалось

Если это правда, то да, скорее это бага.

Как минимум не должно быть такого, что он ждёт 4 секунды, а в сообщении пишет "Timeout: 60 s."

забавно, что этого никто не заметил до сих пор))

Стесняются сказать 😉