We should still fix the security issues, (perceived or real, regardless)

I'll facilitate this. I'll talk to the group about whether there are specifics we want to make sure are delivered within the given topic.

We've discussed offline but just for posterity here -- the biggest issue we have is that these percentages are calculated based on tokens and on wikitext. Essentially, the second author may have edited things like citations and thumbnails and templates that we do not "see" visually in the visual WWT tool, but make his edits correctly account for 2.1% of the page.

This was fixed (incidentally!) as part of the MVC refactor.

Submitted a PR to handle load/unload of VisualEditor: https://github.com/wikimedia/WhoWroteThat/pull/64

This is more about good practice rather than strictly security.

A pre-requisite is to be able to shut off the system (and disable it) from an event handler. Created T234874: Enable WWT to be turned on and off remotely for that task (PR attached) and will follow up with a VE-specific event handler after that one's merged.

For testing, you can now use, in the console:

In T231508#5544348, @Prtksxna wrote:

In T231508#5542462, @Mooeypoo wrote:

[edit] There's also mw.hook( 've.deactivationComplete' ) for deactivation of VE (thanks @Esanders ) that can be used to reactivate the activation link.

If we re-add the WWT link after someone has made changes using VE, will WWT be able to show the newly added content? Or would that require a refresh of some sort?

So after an investigation, here are findings on how we can potentially do this.

You're right, we missed that part when discussing the ticket; it was fixing a code review comment by adding extra functionality.

This is merged to master. I will update the self-hosted gadget in the next few days before it moves to product (if all is well :) .

This was merged, and will be available on beta in a few minutes.

Bringing back to review for this patch.

Thanks to the amazing debug (and git blame) skills of @Catrope we found the problem.

In T230455#5515631, @dom_walden wrote:

@MusikAnimal @Mooeypoo There is an odd behaviour I cannot understand. After opening the "Page info" flyout the articleinfo hook fires, which is fine. But afterwards, each time I mark the page reviewed/unreviewed (without refreshing), the articleinfo hook also fires. First time once, second time twice, third time 4 times, then 8, etc.

@dom_walden I just re-tested this in an effort to figure out what's going on, and I can no longer reproduce it...

In T232460#5505012, @ifried wrote:

@dom_walden Ah, thanks for the clarification!
@Mooeypoo This bug may only be reproducible with the extension rather than the gadget. Do you know why that may be?

In T231943#5508157, @Tchanders wrote:

@Tchanders you're making a good point about this; however, this will only fix the underlying ask tangentially. It would mean that the checkbox being selected won't matter, but it won't actually unselect that checkbox.

Just to help us understand this correctly - are there cases where a logged-in user on office wiki should be blocked if the IP they are editing from is blocked? If not, then we could use the 'ipblock-exempt' option.

In T231943#5505503, @Tchanders wrote:

Forms that pre-populate fields by default will just get it wrong in some cases... Could we get round the problem another way, as suggested above? E.g. setting $wgAutoblockExpiry to 0 or granting the permission 'ipblock-exempt' to all users?

In T231943#5505503, @Tchanders wrote:

I agree that it feels a bit problematic to make assumptions about autoblocks based on the $wgBlockDisablesLogin config. I'm not sure I agree the checking of $wgBlockDisablesLogin and isEveryoneAllowed('read') is much better - it's less impactful, but the principle is the same. (If a wiki with these settings wanted the checkbox checked by default, what would we do?)
Forms that pre-populate fields by default will just get it wrong in some cases... Could we get round the problem another way, as suggested above? E.g. setting $wgAutoblockExpiry to 0 or granting the permission 'ipblock-exempt' to all users?

In T231943#5505070, @DannyS712 wrote:

This is why, originally, I had introduced a separate config variable to control this. However, @Krinkle objected on the patch (https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/534936/) to the addition of a new global setting, instead suggesting that $wgBlockDisablesLogin be used. I have no strong preference either way, but given that just checking BlockDisablesLogin wouldn't be enough, I again suggest that a new config value be added.

First off, thank you @DannyS712 for picking this up :)

Hm I wonder if this has anything to do with the upgrade to jQuery 3.4.1, and that ULS perhaps needs to be adjusted for it.

In T233115#5501893, @Barkeep49 wrote:

It would help if we had any kind of data about the number of triggers this would pull. Would it be comparable to the edit filters?

I'm sorry to hear that. If you ever change your mind, we'll be happy to try and help guide you through the process.
In any case, this page might be able to help as well, if you need it: https://www.mediawiki.org/wiki/Help:TemplateData

In T232168#5472969, @AlgorithmGG wrote:

@Mooeypoo thanks. the manage template button is already active. Is there anyway to have it working as described in the TemplateWizard instructions?

TemplateWizard allows you to insert templates into a page if they have TemplateData definition.
TemplateData extension can help you set definitions in your templates.

If you have TemplateData installed, you can add $wgTemplateDataUseGUI = true; to your LocalSettings.php and you'll see a "Manage TemplateData" button when you edit a template.

@AlgorithmGG TemplateWizard requires having TemplateData definition in each template.

One of the biggest issues here is that we call the hook just before we refresh the page, and that the use cases that this hook is for are working asynchronously, which means refreshing immediately after call is not going to help anything

Sweet! I'm so glad that this is working properly and thank you for the feedback.

Fair enough.

I will remind everyone that we're talking about a WMF employee here.

@sbassett in that case, I just want to make sure we add to the list the fact that Anti Harassment's Tool team's work touches on blocking tools, which inherently tend to be Security tickets if any bug happens there.
Our upcoming work will involve CheckUser, which, again, almost exclusively has bugs in the security realm. For us, this is not just a matter of this being useful, but a pretty crucial part of the work, in case bugs happen in the part of the code we actively work on.

CSSJanus Webpack plugin: https://github.com/mooeypoo/cssjanus-webpack

While doing some experimentation, I unfortunately discovered it's not as easy to get GuidedTour to activate from the injected script; the naming conventions and the fact that it supposed to run on all pages seem to be a bit more difficult for the extension to load itself with the gains of the cookie and toggling.

In T207485#5419052, @ifried wrote:

5. "apihelp-pagetriageaction-param-pageid": "The article for which to perform action on."
   • Potentially change to: “Select this article”
6. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."
   • Potentially change to: “Specify whether the article is reviewed”
7. "apihelp-pagetriageaction-param-enqueue": "If set, the page will be added to PageTriage queue."
   • Potentially change to: “Page will be added to the PageTriage queue”

To QA, use the instructions on https://github.com/wikimedia/WhoWroteThat#testing-the-browser-extension

To QA the browser extension, see the steps at https://github.com/wikimedia/WhoWroteThat#testing-the-browser-extension

Notes so far:

Done here: https://github.com/wikimedia/WhoWroteThat/pull/13

Hmmm but I set up Hebrew as the interface language. Interesting. I'll give it another shot.

First problem: I switched my Chrome language to Hebrew, and I see the site in English, after refreshing and hard-refreshing a few times.

Yup, although I might need that language picker ... ;)

• When WWT is activated, a blue information bar should appear at the top of the article.
• The information bar should be displayed below the links ("Read," "Edit," "View History," "Article," or "Talk") and above the article title.
• I've checked on this for Vector, Monobook and Timeless. There are minor annoyances with the icons in Monobook and Timeless, but it is working.
• The information bar should not block any links on the page.
• The whitespace dimensions at the top of the article should remain the same.
• The information bar should be sticky.
• The information bar should be implemented in such a way that it can adapt to different states. For example, if there is an API error, the bar may change (e.g. a different color). However, the actual handling of error behavior will be covered in a separate ticket.
• The widget changes state with widget.setState( state ) where state can be pending, ready, and err.

This PR fixes the following:

• Add a link/button to toggle WhoWroteThat view on/off on the sidebar, under "Tools
• The text of the link should read as follows: "Who Wrote That?"
• The "Who Wrote That" link should be the last in the order of tools (i.e. do not change the current order)
• If a user toggles on WWT, the WWT mode should display on an article page
• If the user toggles off WWT, the WWT mode should no longer display on an article page
• This should only appear in "Tools" when the user is viewing an article page in Read view.

I have a PR for this here: https://github.com/wikimedia/WhoWroteThat/pull/16

\o/ Thank you @Samwilson !