PR at https://github.com/nicholasray/pixel/pull/58

In T311259#8026088, @Jdlrobson wrote:

@nray was this fixed by https://github.com/nicholasray/pixel/commit/7afcccc17786f680c0d35692a6392028df07c553 ?

Thank you for all the reviews @Jdlrobson! I think given that the last two commits from https://github.com/nicholasray/pixel/pull/39/ introduce additional docker container complexity combined with the fact that I'll be on sabbatical after next week, we should hold off on merging those. I think they would probably do more harm than good right now. For now, I'll decline this task, but I may want to revisit this in the future

Yes, we can hide elements by including hideSelectors: [....] in the scenario

https://developer.chrome.com/docs/devtools/coverage/ might be helpful here

Ready for review!

Remaining goals for this month are captured in T309742

In T309742#7984231, @Jdlrobson wrote:

xel's report on https://pixel.wmcloud.org/ and cron job should survive the Wikimedia Cloud VPS server restarting. Currently, I believe manual intervention is required to start es-dev-server and screen as described in T305563#7879426 . Can we point the apache server that is already setup at the report's static directory and remove es-dev-server?

This is already done so marking.

I'm noticing an error in my local dev environment, and I'm wondering if this patch is related. Please see the comment at the bottom of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/803086/

In T309742#7977230, @Jdlrobson wrote:

The CI job that currently only runs the desktop tests for each PR should be changed to run all tests and should block merging into the main branch if they fail.

Is this one within our control or do we need help from RelEng? I'd rather not take this on if we need their help.

@Jdlrobson @ovasileva As requested, here is the new ticket for the remaining visual regression tool work that would ideally be completed before I leave for sabbatical

Great job @bwang !

Will be done as part of T307936

I'm happy to help with this if interested. As mentioned in T291525#7919512, the web team has been using visual regression testing for the last month and we've found it pretty useful. Personally, it cuts out a lot of the manual testing that I used to do for code review because it very efficiently captures a variety of viewport widths and pages that would have otherwise been very tedious to review manually.

https://gerrit.wikimedia.org/r/790765 is being deployed everywhere this week and will go into effect when a user has enabled the setting in their OS. One side effect I've noticed with this change is that, at least in Chrome and Safari, frames can be produced of the mobile sidebar that show it without icons/text for a short duration.

Thank you for your response @hashar. I have a follow up question below (I'm also happy to meet with you if that's easier):

@cjming Should this be moved back to code review given there is an outstanding patch?

I envisioned this wouldn't require much more than running a rm -rf report/test-screenshots command before the ./pixel.js test command starts and can done entirely inside pixel.js. I don't think it needs analysis

Apparently there is a workaround using query parameters that overrides this behavior so that if you navigate to new pages by clicking on links from within the current page, whatever TOC is visible on the current page will be carried over to the next pages using query params. As confirmed by @nray, we are trying to preserve a user's bucket by highjacking clicked links within the current page using the tableofcontents query param. Notably though, the same web_session_id having different buckets is a drawback of bucketing based on article id in order to test anonymous users. This bucket preservation effort can be easily bypassed by navigating to urls directly, clicking links via organic search,

@Jdlrobson This is also ready for the kanban board whenever there is space/time