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.
Fri, Aug 16
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
Wed, Aug 14
Fri, Aug 9
Notes so far:
Thu, Aug 8
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.
Wed, Aug 7
Tue, Aug 6
Mon, Aug 5
This PR fixes the following:
Sun, Aug 4
I have a PR for this here: https://github.com/wikimedia/WhoWroteThat/pull/16
Wed, Jul 31
Mon, Jul 29
\o/ Thank you @Samwilson !
Fri, Jul 26
Wed, Jul 24
Tue, Jul 23
Reviewed, tested. Resolving this ticket. Hopefully this makes this easier also for the sister-ticket T227527: Implement build steps for WhoWroteThat as a gadget
Mon, Jul 22
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
Jul 19 2019
These look great!
Jul 17 2019
Jul 15 2019
Jul 11 2019
@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?
Jul 9 2019
Thanks, @Marostegui -- I edited my comment to reflect the new estimate.
Jul 8 2019
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.
Jul 5 2019
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:
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:
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?
Jul 4 2019
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.
Jul 3 2019
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.
Jul 2 2019
Original repo: https://github.com/mooeypoo/WhoWroteThat
Jun 27 2019
From the engineering meeting, we hashed out next steps for this:
Jun 25 2019
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.
Jun 21 2019
Jun 20 2019
@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:
Jun 19 2019
I am a little weary changing this behavior inside the toolbar itself.
Jun 16 2019
Jun 13 2019
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.
Jun 11 2019
Jun 5 2019
Jun 4 2019
May 31 2019
Yes, I don't think that's a problem, that's the intent.
May 30 2019
May 28 2019
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.
May 24 2019
PR available: https://github.com/wikimedia/svgtranslate/pull/114