Mostly done but there is a juicy refactor to take care of still: https://gerrit.wikimedia.org/r/392890
Done...? T127405 captures the remaining work.
This can be done only using css
I think this is oversimplifying things. We'll need to be careful here as these are 2 very different menus. We'll need to think about how we ship the HTML, the CSS and JS. Can you expand on what you mean by this?
Now fixed in production
I finished exploring this and the resulting patchset details the remaining issues, but refraining from pulling into code review column until we have bandwidth to review. We should also take the time to read through and understand the issues before committing to continuing with this.
I'm not sure what the align layout would be called as I'm not sure how alignment is used in VisualEditor but you can see my workaround for this here:
Tue, Nov 21
@Aklapper one 2 hour task should be enough and contributor doesn't need to be experienced - just needs to know how phpcs works. Yes I can mentor.
See Problems with existing implementation and T146396
The existing implementation is a little slow on large articles for the first view, but fine on the majority. When the new REST base references endpoint is available we will be able to speed this up significantly.
A few of reading are working over Thanksgiving so it might be useful to be able to test on the beta cluster as early as today. @ovasileva would be the right person to confirm with about that.
Mon, Nov 20
#2 is obviously the easier (maybe a 1 pointer) but I'd say #1 is the correct thing to do, but a little harder (i'd estimate 2-5 points depending on how much upfront investigation we do with regards to how to obtain the download URL)
No errors in last 2 weeks so looks fixed:
Sure enough, the tests have recovered over the weekend. I don't suggest investigating this more. Let's focus on getting them ported to Node.js
Sat, Nov 18
Fri, Nov 17
@bmansurov let's come up with testing criteria for this card on Monday. Also who do we want to do this QA? Let's make that explicit. Anthony? Tilman? A developer?
This is showing up on https://gerrit.wikimedia.org/r/#/c/391985/1 ...
This has always been the case and I suspect it is because of the sheer amount of tests that are run. The probability of one failing is thus higher. In addition to this, the success of the tests relies on the stability of the beta cluster and Saucelabs.
We'll pull it into next sprint. No need to track it here as it will just be blocked for 2 weeks.
I'm not 100% it's going to solve the problem, although it seems like it will, but we can talk about it in a future grooming.
Thu, Nov 16
@Tgr yeh that does look like what's happening here. Review welcomed :)
While working on this I also discovered a bug with how we display revisions.
The box should be styled and is simple to fix. Not sure if we want to track that separately.
After looking into this, I see that desktop does not show a timestamp either, so I propose we show a link to "view edit history of page" as we do on Main page for these kind of pages like so:
It does look like it could be deploy related. Spikes were on 3rd Nov and 10th Nov but only happened in the last 2 deploys.
The RelatedArticles extension could expose these via a RelatedArticles page property if needed.
Currently it uses ParserOutput->setExtensionData rather than ParserOutput->setProperty so no data is currently stored in the database and thus not accessible via an API.
@Pchelolo asked me a few questions
The goal of the alignment is to have 2 checkboxes and 1 select dropdown right aligned for mobile.
I've raised a bug for the more serious issue here - T180730. I hadn't even got round to testing how it behaved on a mobile device!
@Fako85 The error message is "Cite extension reference storage is not enabled."
To my knowledge this was never enabled in production. You may want to open a new task against Cite extension to investigate that.
I should notice usage seems a little higher today on Minerva (4x already) and already has surpassed yesterday's usage (1301 events) despite it being only 6pm UTC time:
This fits a hypothesis of HTML caching/discoverability of a new feature.
You can manually test this already for increased confidence.
To do so put the following code in your user minerva.js to force on bucketing:
Or to put it differently: Has someone checked that the onBeforePrint/ matchmedia event (cf. T171162#3457776 ) behaves as expected for Chrome mobile on Android?
I don't see any specific record of us testing Chrome on mobile (I don't actually see much QA on T169730), but we did implement matchMedia per suggestion of @bmansurov specifically for Chrome.Llooking at the data, I am seeing events from Android Chrome on Minerva on the mobile domain. We wouldn't be getting any events if that wasn't working.
@Nirzar I spent some time understanding OOUI a little more and I see a problem with the proposed design and the select menu. On a mobile screen the labels of the dropdown and the accompanying text conflict (and if the translation text is longer there will be more problems)