In T244160#5875146, @MMiller_WMF wrote:

@Etonkovidova -- since this is covered in T224883, do you think that this task should be merged into that one? If so, could you please merge?

@dom_walden - events for certain schemas can be viewed in the Dev Console with some javascript snippets. Let me know if you need it for testing.

@Urbanecm
Checked on enwiki betalabs.

Re-checked the notifications types that were described in the task, i.e.

• a page was reviewed
• a page was linked

The same error appears on RecentChanges too.

There is another report - T245139: "TypeError: this.emptyFilterMessage is undefined" on Commons Watchlist.

Checked in betalabs:

What found when re-testing the current behavior
(1) Records of deleted Flow board content (deleted posts and topics) will be displayed on Special:DeletedContributions (and not in Special:Contributions) under the name of an admin who deleted the content:

In T238945#5875156, @MMiller_WMF wrote:

@Etonkovidova -- should this still be in your column? Or are there next steps that someone should take?

In T242808#5811800, @Catrope wrote:

I can't reproduce this on desktop Chrome (with or without mobile emulator), desktop Firefox (with or without mobile emulator), or mobile Chrome (on Android). Does this only happen on iPhones? Does it happen in desktop Safari too?
Also note that in the screenshot, it doesn't happen to all topics: "Geografie" isn't broken.

Due to T244928, there were quite few error details recorded in betalabs eventlogging in the following format (all errors were found in deployment-eventlog05:/srv/log/eventlogging) :

Checked in wmf.18.

Unless I'm missing something here, the issue seems to me as an intended behavior.

Click filter changes input to open the filter changes menu
Click the delete icon

Re-checked in Safari 10.1.2 (the same version the issue was reported) - it seems that the issue is not present anymore.

Checked in betalabs - did not see any problems with Echo UI display with desktop Minerva.

Checked in betalabs

Re-checked to see the current behavior. To summarize

• The issue (not being able to close Other review tools) is present only if Javascript is disabled for a browser used. It doesn't matter which skin (or desktop/mobile) is used.

Checked in betalabs on a real iOS device - the issue is fixed.

Thx, @Zoranzoki21 - the issue was noticed and reported in https://phabricator.wikimedia.org/T224883#5824325. Moving the task into current sprint for further team discussion.
Testing on arwiki showed that there are few other cases when the proper position of the arrow looks problematic:

I've added the task to pre- and post-deployment (wmf.19) checklist. In betalabs the translations were not yet displayed.

Re-checked in betalabs and production - the issue is not present anymore.

In T242814#5830760, @Tgr wrote:

Honestly, I don't think anyone will care about it. Search result counts are often a bit strange since counting large sets are hard and search engines tend to cheat in various ways (try paging search results in Google or Gmail for example and watch how the counts fluctuate).

In T238613#5794394, @Tgr wrote:

How did that happen? It shouldn't be possible to see the no results card and a task type description in the same time.

In T243307#5828470, @MMiller_WMF wrote:

@Etonkovidova -- could you please add what you think should be changed?

Re-checked T242814 as part of testing this task - some discussion (possibly) is needed.
This task as Resolved.

In T242814#5821500, @Tgr wrote:

This seems to me like a duplicate of T243036 but maybe I am misunderstanding the issue. Is there anything here that would be left after T243036 is done, of that could be done without resolving T243036?

The task has been checked ( some issues - T242476: Newcomer tasks: when selecting multiple topics, one topic should not dominate over the others (and the comment https://phabricator.wikimedia.org/T240512#5793805)- will be addressed in separately).

Checked in betalabs and in production - selecting all topics and all difficulty levels (and do less extreme queries but still extensive queries) does not fail. However, the is a difference in count of articles between the topic overlay count and the task card counter. Often the right count appears only in the task card but not in the topic overlay. The issue would be addressed in separate tickets.

In T243035#5814967, @Tgr wrote:

The module uses more random results (roughly identical to using the API with gglimit=250 instead of 10, ie. top 250 results instead of top 10), to avoid all users who select the same topics getting the same tasks.

In T243038#5812011, @Tgr wrote:

This is the same as T242814: Newcomer tasks: Discrepancy in article counter on "Select your interests" : we display the real result count (how many matching articles are there on the server), not the task card count.

When Advanced mode is enabled on mobile, the arrow will incorrectly point to the menu that does not have a username link:

• the hamburger menu does not have the username link in Advanced mode

• the user name link is on a different side

Checked in betalabs - the arrows are positioned equally

Checked in betalabs and moved for a Design review - please note the divider between topics and difficulty filters seems to be of double width.

Checked in betlabs - no issues found.

Re-tested https://gerrit.wikimedia.org/r/565459 - the test cases from task description show the same incorrect results. I corrected the case for - it should 4, not 7 as it was reported before: (correction) Zdraví + Společenské = 4

Notes for testing - check the test cases in T242814: Newcomer tasks: Discrepancy in article counter on "Select your interests"

Moving to Design review/evaluation. I filed another task (rather minor) - T243307: Newcomer task: Article card - adjust the info icon size and position on mobile

@Tgr - on iPhone 6S (and browser emulators) the label is moved to the end of the line

@Tgr - was it intentional for hover-in/hover-out events associated with SE dialogs to have additional action_data?

 select event_module,event_action,event_action_data from HomepageModule_19528052 where event_action like'hover%' group by event_module;
+-----------------+--------------+----------------------------------------+
| event_module    | event_action | event_action_data                      |
+-----------------+--------------+----------------------------------------+
| impact          | hover-out    |                                        |
| start-account   | hover-in     |                                        |
| start-email     | hover-in     |                                        |
| suggested-edits | hover-in     | taskTypes=copyedit,links;taskCount=200 |
+-----------------+--------------+----------------------------------------+

Confirmed - the issues is present in betalabs.

The implementation of the specs in the task description have been checked and seem to be fine, except there are two bugs in the footer counter

• T242814: Newcomer tasks: Discrepancy in article counter on "Select your interests"
• T243038: Newcomer tasks: article counter in Start editing dialog footer displays more than 200

Checked in cswiki wmf.15 after the hidden preference deployment - the newly added eventlogging events are present (checked in the Console).

Checked in all target wikis - seems to be working as expected.

Several things to consider

In T238612#5792467, @kostajh wrote:

The only exception is that whereas the intro overlay updated the article count based on the default difficulty level settings for user initiating suggested edits, this filter dialog should update the article count based on whichever task types the user has selected at the time they are interacting with the filter.

As I'm looking at this, cognitively, I find it weird that the counter shows 200 articles even when all topics are deselected. The 200 count is correct because it queries by the task types I have selected, but we might want to think about hiding the article counter until the user selects some topics.

Re-checked in regards of recent patches - ready for Design Review.

Moving to Design Review - the specs marked with a green exclamation point have not been implemented yet.

For Design review - the line spacing and font (?) for "We'll try to suggest..." subheading looks different from the mockup.

The actual functionality of the button will be checked in T238612: Newcomer tasks: topic filters

I see the same as in @Gergo comment above.