If my description sounds entirely vague or nonsensical to you, it's probably because it is! I'm having trouble articulating the approach I'm proposing, but I'm spending some time today to work out a POC patch that will hopefully explain it much better!

Please see https://phabricator.wikimedia.org/T245456#5901923 for the latest on this task. I think figuring out the correct approach for that ticket is actually a prerequisite for this ticket and is what I'm focusing on right now

I've been looking at @Jdlrobson's POC patches related to template partials in trying to determine how to do T243281 (Note the note at the top of the task!). So far they look good to me, but I'm trying to work out if the following AC is the right approach:

@Volker_E Regarding users who mistakenly click the button, my understanding of the AC is that the button is simply a link to the user preferences page appearance tab and that clicking on it will not actually perform the toggle (users will still have to opt-out after clicking the button)

Path has been +2'd, I just need to add QA steps which I'm doing now...

a composite - for example only 100 edits that visits a specific namespace $set = new CompositeSet( [ new VisitingNamespace ( NS_TALK ), new ContributorEditsCheck( 100 ) )

https://gerrit.wikimedia.org/r/571841 is ready for review which replaces the duck with the doc.

Okay, this is probably a bit of scope creep now but there actually is one more patch I'd like to get merged before this task is resolved:

Just a check with Web that you're OK with this change and it doesn't go against any plans. If you're OK, I deploy it later today.

I will look at this today

@phuedx Not anymore, I think this is ready for sign off now, There are still some topics I'd like to discuss in our next shdt whenever that may be, but I don't think that should block the resolution of this task.

Remove the notion of groups from the system. AFAICT Feature#getGroup is only ever invoked in a unit test. Therefore, it only serves to increase entropy

We (@Jdrewniak, @phuedx, and I) voted this as a medium today in part because there is chance to unify client side edit count bucket related code with the code that lives in onUserSaveOptions. @phuedx could you remind me again where the client side code lives that we would want to unify?

In T242491#5805756, @ovasileva wrote:

Good point. How about "Advanced mode provides expanded functionality of History pages, Watchlist pages, Recent changes, and other editor tools on mobile". Still not perfect, so open to suggestions

I think removing it as a quarterly goal makes sense for now as I think we have more important things we can focus on first (e.g. I certainly wouldn't prioritize it over adding unit tests in vector and some of the other foundational work that we've discussed for desktop improvements). However, I do plan to invest more time in this in my 10% time as I still think it has potential to help.

@ovasileva What would you like the updated copy on the amc outreach drawer to be? It is currently:

Found a regression on talk page that needs a fix:

Here are the main points I have surrounding visual regression testing:

Patches to review:

@Jdrewniak That's a great idea, and I took a shot at doing this in:

I made a minimal test case of the bug at https://quizzical-bhabha-d9a97e.netlify.com/. Notice the red box moving down when the page loads in chrome - that shouldn't happen as the only css is the following:

The video attached is what I'm seeing.

@Jdlrobson I've been able to replicate it on the latest Chrome version 79.0.3945.88 (Mac) so I don't think the bug has been resolved yet. The bug ticket is still open too.

I think this is because of the .animations class which is added via JS for historical reasons. I think we have a bug somewhere to remove (and if we haven't got a bug we should create a bug to do that!)

So I have two patches ready that should knock out the .animations class and the supportsAnimations method, but the only problem is I think this makes the chrome animation flash bug (https://bugs.chromium.org/p/chromium/issues/detail?id=332189) rear its ugly head again.

In T230695#5725570, @alexhollender wrote:

In T230695#5691655, @nray wrote:

I recommend opening a new ticket if this is still a problem as I don't think the fix will be trivial

It looks better currently than it did when I took that video. Regarding further fixes does this task describe the work we'd need to do? T219388

Thanks so much to all the people involved in making this happen (FAWG, @Niedzielski, others)! The points outlined in the RFC are articulated very well, and I am excited for the future ahead

@sbassett gerrit patch has now been updated at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/559557/ and ready to be deployed. Thank you!

Attached is the patch to add all of the listed messages + 1 other one in the RawHtmlMessages array. I'm not sure if putting the patch here matters since I already screwed up (I think) and pushed the patch to gerrit (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/559557/) before realizing this task was set to hidden. I'll try to be much more careful about this in the future.

@ovasileva @Edtadros This is now ready to test on mediawiki.org. QA steps have been updated with new urls as well as more explicit info. @ovasileva feel free to double check the qa steps I updated, I think think they reflect what the AC should be but it probably wouldn't hurt to have another pair of eyes on it

Given that the AC listed in this ticket is part of T232653 (which also has the necessary QA steps), I propose we close out this ticket

In T238364#5738271, @Jdlrobson wrote:

Looking into this some more, I think the URIs that are not impacted by the table of contents bug can be fixed with a simple encodeURIComponent. That's what my patch does. AS for the other characters - that should be handled in the parser.

thanks @sbassett . Yes, I think that's more of a bug than related to the xss vector. I'll open a separate ticket for that. I appreciate all of your help along with @suffusion_of_yellow !

<h2><span class="section-heading"><span class="mw-headline"><img src="blah.jpg" onmouseover="alert('XSS')"></span></span><span class="mf-section-1">blah</span></h2>

In regards to the above example where the overlay opens automatically on page load, I think the is due to that .section-heading element which the code interprets as a valid section and since its child .mw-headline element doesn't have a id on it, the router opens the overlay thinking it matches a route without a hash.

@Reedy @sbassett I think this does unfortunately have an impact on production. I think it occurs because of the following line which unescapes escaped html:

I spoke too soon. I think this could impact production on certain browsers where the overlay is able to open. There is currently a bug T238364 that prevents the overlay from opening in certain browsers with certain characters. Given that the characters > and < are relevant here, that ticket shows that safari 13.0.3 and iOS Safari 12.0 (probably others) are able to open the overlay and could be impacted.

Thanks for brining this up. I believe this has impacted 3rd party wikis only as our wmf-config has the following config:

I've moved this ticket to doing as the work for T232653 is closely related to this work considering the contributions icon should be part of the toolbar on both user pages and user talk pages for logged in users (https://phabricator.wikimedia.org/T232653#5730229)