Fri, Feb 21
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!
Thu, Feb 20
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:
Wed, Feb 19
@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)
Tue, Feb 18
Path has been +2'd, I just need to add QA steps which I'm doing now...
Fri, Feb 14
a composite - for example only 100 edits that visits a specific namespace $set = new CompositeSet( [ new VisitingNamespace ( NS_TALK ), new ContributorEditsCheck( 100 ) )
Thu, Feb 13
https://gerrit.wikimedia.org/r/571841 is ready for review which replaces the duck with the doc.
Tue, Feb 11
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.
Sat, Feb 8
Thu, Feb 6
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
Wed, Feb 5
Jan 21 2020
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?
Jan 16 2020
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.
Jan 14 2020
@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:
Jan 13 2020
Here are the main points I have surrounding visual regression testing:
Jan 11 2020
Jan 9 2020
Jan 8 2020
Patches to review:
Jan 7 2020
@Jdrewniak That's a great idea, and I took a shot at doing this in:
Jan 6 2020
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!)
Jan 2 2020
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.
Dec 20 2019
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
Dec 19 2019
@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.
Dec 18 2019
Dec 17 2019
@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
Dec 16 2019
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
Dec 14 2019
Dec 13 2019
<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.
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:
Dec 12 2019
|Anon user page||Anon user talk page||Logged in user page||Logged in user talk page||AMC user page||AMC user talk page|
Dec 11 2019
Dec 10 2019
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)