T215675 is a blocker, we need to decide on how to dynamically tag log entries before we can do this task.

FeaturesManager::isFeatureAvailableInContext will go away, there were no changes to the isFeatureAvailableInContext, only deprecation. It's deprecated because Minerva is still using it, after we're done with Minerva changes we should be able to remove isFeatureAvailableInContext method.

In T214180#4934787, @pmiazga wrote:

@nray - yes, that is correct, and for now lets keep it that way. I know that there are some ideas to remove the mobile domain (I have no idea if this is going to happen)
@alexhollender - we can add some param to the the URL, like https://www.mediawiki.org/wiki/Special:MyLanguage/Talk:Reading/Web/Advanced_mobile_contributions?amc_source=optin (I wouldn't worry about caching as this is served to logged-in users only). Then with we would have to query hive to get the number of page views with that GET amc_source param. Difficulty - easy to medium. /cc @Tbayer

@ovasileva @Tbayer clarification question so we are all on the same page. When should we tag "thanks" action with advanced mobile edit? I see two possibilities - when user who performs the action has amc mode enabled (when performing action), or do we want to tag thanks action when the revision thank is sent for was made with amc mode enabled?.

As Tbayer mentioned, I created separate task to tackle the tagging actions done via Thanks extension - T215477. I did a quick check and it should be possible but definitely it doesn't look trivial.

@Tgr I assume you're still waiting for answers from @ema? Is there anything I can help you with?

I'll ping @mobrovac once again, as he decided to use internal domain names (previously we were using the public domains).

@Tgr so far we were bumping Puppeteer version and usually everything works. There was one problem with headers (chromium wasn't sending the headers we're asking for) but most probably that was the puppeteer lib issue in given version, not the conclict between two different versions. After we bumped to the newer release problem went away. We started chromium-render development from Puppeteer 0.11.0 (https://github.com/wikimedia/mediawiki-services-chromium-render/commit/d02e5a57ec1e986f0992edaf6b8c8169d13b5203#diff-b9cfc7f2cdf78a7f4b91a753d10865a2) and so far update process didn't cause any troubles (currently we're on 1.9.0)

Quick question - do we want to track clicks on those links (how many people visit Learn More and Send feedback) ?

I'd love to find out, what takes the most of the time during web request. The error message is not that processing that single part of code took more that 60 seconds. Timer starts when server receives the request, and when it runs out of time it just stops the execution and prints the current stacktrace, The MobileFrontend can be definitely an offender here (parsing huge DOM structures) but definitely there are other parts of code that just take time to process. For example there can be something that took over 50 seconds of the request time before MobileFormatter came into the play. If that happens most of the time, I wouldn't worry about the MobileFrontend transforms. But if the MobileFrontend transforms takes most of the request time - then it's definitely something we should look at.

Last acceptance criteria says that we will remove usage of the jQuery lib, but the jQuery is still required for Deferreds and declaring types for function params, and attaching eventListeners.
Do we want to drop that last acceptance criteria?

The acceptance criteria says We will add test coverage for the Skin class but Skin.js has no coverage.

Confirmed, and I see two issues here:
A) Captcha is filled in, but not visible in Wikitext editor, in visual editor it works properly.

@Jhernandez I'll update documentation once all Tgr questions are answered.

getPluralLicenseInfo() is fully covered. Resolving task.

Looks good.

@Tgr - Public Wikimedia sites and Beta certs are set for public domains. Proton render used to access Wikipedia servers using internal network names (as it was inside internal network). The internal servers use the CA generated by Puppet.
Switching between HTTP/HTTPS modes is available via config (the config file has the URL template used to build the article URL).

In T213371#4901265, @Tgr wrote:

What IMO we need to know to understand how the service will deal with spikes:

There is a queue mechanism. Each proton instance can only render X of jobs at one time, and Y jobs can be queued. If the spike is higher than X+Y every new job will be rejected with HTTP_503 error including the Retry-After header. Then the pool manager will de-pool that instance (allow it to peacefully render all jobs).

Done : documented how to perform updates and wrote down why we do it this way: https://wikitech.wikimedia.org/wiki/Proton#Updating_Puppeteer_&_Chromium

Done: https://wikitech.wikimedia.org/wiki/Proton#Puppeteer_configuration

We cannot remove the --ignoreHTTPSErrors flag. It was added to the config https://github.com/wikimedia/mediawiki-services-chromium-render-deploy/commit/17fc7bb4cda2e1b408d6289c27685624d35e8714 because:

We use a self-signed certificate for our domains (since the CA is our Puppet). However, that results in Chromium HTTPS errors. Given that Proton cannot communicate with the outside world, it is safe to use the ignoreHTTPSErrors configuration flag since requesting HTML from our appservers is all the service does.

If I understand this task right (the AMC mode has to be disabled on production for now - not visible on Special:MobileOptions page), this development query parameter has to supersede the MFAdvancedMobileContributions config flag (enable the AMC mode and enable AMC for currently logged-in user). It looks bit scary, as the beta mode is available on production, and the mobileaction only temporarily enables the beta mode for the current user.

Deployed to English Wikipedia.

@ovasileva FYI: current implementation of AMC revision tag is identical to the mobile web edit tag. If the AMC tag doesn't appear on some moderation actions - the mobile web edit tag will not be present.

@daniel @Tgr - could check whats causing this issue?

As an interim solution - which most probably will provide enough of security - let's provide:

• a config variable, where we can store a regex to whitelist URL [or possible an array of regexes]
• if the config option is set, use the Page Request Interception, if it doesn't match the regex abort the request?

@ovasileva @Tbayer - just out of curiosity - both advanced mobile edit and mobile web edit are redundant. Do we want to keep both (keeping both is much easier, showing only one - mobile web edit or advanced mobile edit is bit more complex). I'm just thinking aloud. The current implementation will add advanced mobile edit tag everytime AMC mode is on. That edit will be marked both with advanced mobiled edit and mobile web edit. Is it ok?