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.

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.
• This is only working for Vector for the moment. We'll need to adjust it for monobook if we're interested in supporting it. @ifried
• 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:

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

\o/ Thank you @Samwilson !

Reviewed, tested. Resolving this ticket. Hopefully this makes this easier also for the sister-ticket T227527: Implement build steps for WhoWroteThat as a gadget

I have a PR on the private repo (we need to move that repo under Wikimedia) but I want to make sure someone takes a look before it's merged: https://github.com/mooeypoo/WhoWroteThat/pull/1

These look great!

In T184144#5323529, @FaFlo wrote:

@ifried Hey Ifried, nice to meet you and good to hear :)

What concerns would you have about using the WhoColor API to retrieve data from older versions of a page?

None, you can call any revision of an article and get back the tokens at the time that were in the revision and their history.
The only "weird" but intended behavior here is that the lists of in and outs will also "look into the future" for tokens in older revisions (see example here for token_id: 31614 , but you can simply ignore those with higher revids than the oldid you have retrieved.

@Niharika , correct me if I'm wrong, but for option 2 we actually don't need to retain the User ID; The entire row is a picture of what random-user did in the form, so the user id or username itself doesn't matter. Is that right?

Thanks, @Marostegui -- I edited my comment to reflect the new estimate.

Created an actionable ticket T227522: Implement build steps for using WhoWroteThat as injected script

We've discussed this (and the wider implication of the entire feature) in the Engineering meeting, and agreed it's time to revisit whether the product is worth the significant effort here. We tried to estimate, generally, how long things may take.

OK, it looks like there's agreement that the strategy is sound and acceptable. In that case, I am going to summarize it with an action plan for the team. Please see if this makes sense or if I missed anything:

Alright, now it's working:

In T227160#5310196, @Krinkle wrote:

I don't know much about how browser extensions work behind the scenes, but I believe the following are mutually exclusive:

• JavaScript code is actually executed in the context of a browser tab.
• JavaScript code has access to a library automatically loaded by the browser (in your case, a copy of jquery.js).

I might be missing something here, but this didn't work for me. The browser extension itself requires jQuery, so I can immediately use $( document ).ready() in the contentScript just for that. So, I tested this:

In T227160#5310136, @Krinkle wrote:

In T227160#5310123, @Catrope wrote:

Yes, you're right, you can't use mw.loader.using(). You can use mw.loader.load() though.

Both are defined asynchronously and both may be absent initially. mw.loader.load is part of the startup module and while that is loaded from an async script tag, it is guaranteed to be executed at domComplete/window-onload because it is a sub resource (just like images, stylesheets and synchronous scripts). However, domInteractive/dom-ready does not guarantee it.
The mw.loader.using method is ensured to be available for any ResourceLoader module is executed, but actually ships as part of an implicit default dependency for all modules (called "mediawiki.base"). And downloads in parallel to regular modules. This is an implementation detail, but it means that if you're observing from the outside, "window-onload" will not guarantee presence of mw.loader.using.
But... none of this matters. This use case is exactly why RLQ exists. Use the following:

myStuff.load = function () {
 /* This can use mw.loader.using(), and jQuery etc. */
};
var q = window.RLQ || ( window.RLQ = [] );
q.push( [ 'jquery', 'mediawiki.base' ], myStuff.load );

Then everything will work as expected. No timeouts, dom-readies, custom jquery, or other things required.

I have an alternative idea building off of yours that will allow us to lazy-load our dependencies when we need them, rather than immediately.

Wait, so, if we go with mw.loader.load on a module we implemented *and* defined as having an OOUI dependency, then, technically, mw.loader.load() is sufficient. We won't need to wait for dependencies and THEN run the code -- the definition itself does it for us.

Ooh! This is interesting. My only question, though, is that wouldn't we be facing the same problem of running mw.loader.using( 'whowrotethat' ) too early? The main issue we're running into is that the pageScript that's injected is in itself running to early, so even if we use the available infrastructure to create a module, wouldn't we still have to wait for mw.loader.using to be available in order to instigate the actual loading of the script?

Some preliminary investigation on my end shows one direction we can go with. Chrome extensions are sandboxed; that is, the extension code itself cannot communicate with code inside the tab, and whatever is inside the DOM cannot communicate with the Chrome browser API. This is done for security reasons, and is understandable.

In T226774#5302416, @Prtksxna wrote:

Thanks @Mooeypoo! Quick question, is it possible to have markup inside OOUI popups like headings and stuff, as is the case with GuidedTours?

Honestly, I'm hoping we can do it so we can also use ooui pop-ups in general. From my experience, they're vastly superior to anything else out there when it comes to proper positioning within cross directional text with cross directional interface, which is pretty necessary for wikis.

Just to be clear before anyone jumps ahead of the train (of thought;) we need to check into whether this is feasible and follows our security and privacy standards.

Actually, I've been reading about how we might be able to reach into the available global variables in the DOM with a browser extension. Since we know it only runs on Wikipedia sites, if we can do that, we will have access to the mw variable, which means we can use resource loader to load (and use!) Guided Tour.

Original repo: https://github.com/mooeypoo/WhoWroteThat

From the engineering meeting, we hashed out next steps for this:

I have a radical suggestion here... since the demos were written in what the IT universe defines as "generations ago", I think that instead of thinking about how to fix performance for what's built, we should reassess whether the demos -- in general -- need to be rewritten.

@FaFlo , we took a closer look at the response we're getting from articles that break, and we found that the cause seems to be that the process is running out of memory. See:

I am a little weary changing this behavior inside the toolbar itself.

In T225571#5260481, @Mainframe98 wrote:

Will there also be a PHP variant of this widget?

Yup, that would work as well; I wasn't sure if it was okay to change that without some agreement from community if the bot is widespread, which is why I (wrongly) assumed that wasn't an option :)

I was thinking about this -- I don't think OAuth is enough to stop this behavior. We will need to add a check about whether the user is also blocked, potentially from the page they're asking the bot to edit.

In T206163#5238240, @Tchanders wrote:

What name do we prefer? So far the suggestion is CompositeBlock which sounds good to me.

Yes, I don't think that's a problem, that's the intent.

In T224245#5225204, @MaxSem wrote:

Yeah, I've corrected my text.

In T224245#5225176, @MaxSem wrote:

• When such a setting is getting modified, GlobalPreferences intercepts this and, if the option is global and not overridden locally, a local value is set instead. Modifying a locally overridden value transparently should already work as expected (but we need to verify this regardless).

There's not a lot of specifics to test here, but we should just verify that things didn't break with this on beta.

This is an interesting discussion, but it's not quite for this product to make the decision. We read the spec off of TemplateData which allow template owners (and wikis) to set the templates the way they wish they behave for better behavior both on the wiki as well as while being edited by this tool or VisualEditor.

Actually, that's a great catch; this should probably also be the fallback for wikis where Echo isn't installed.

Yeah, this fix is mostly only for the UX of the tool and should not impact the actual SVG file.

PR available: https://github.com/wikimedia/svgtranslate/pull/114