Yes, I've been working on some higher priority issues (this is mostly just a cosmetic problem) but I'll look into it now.
Probably my changes from T167616 caused this :(
Tue, Jun 27
Interestingly, while it's not visible normally because of the node highlights overlaid on top of the template, the links actually point to subpages of my user page – e.g. https://en.wikipedia.org/wiki/User:Matma_Rex/CSI:_Crime_Scene_Investigation_(season_1) and so on. And VE runs API queries to check the status of those pages, which indeed do not exist. (Even more interesting why some of them, like https://en.wikipedia.org/wiki/User:Matma_Rex/D.B._Russell, are considered to exist…)
@Nnvu I only see this issue on specific pages, rather than everywhere. Is it the same for you? Can you five a few examples of broken pages?
Did a pullthrough in https://gerrit.wikimedia.org/r/361679, that fixes it for me locally.
An empty message was intentionally added in https://gerrit.wikimedia.org/r/#/c/358731/. "While that should be fixed by someone familiar with this extension, the new message does still need to exist whether empty or not."
https://translatewiki.net/wiki/MediaWiki:Apihelp-parsoid-batch-summary/qqq does exist, though. Weird.
This is only an issue with popups on hover, rather than on click. I fixed it by making the area below the button (see my screenshot above) still trigger the hover effect.
Mon, Jun 26
You would only need to load 'oojs-ui-core', instead of 'oojs-ui-core' and 'oojs-ui-widgets'. That's a difference of ~20 KB after gzip (120 KB before gzip).
I proposed https://gerrit.wikimedia.org/r/360771 for that.
With this change, it will no longer be possible to use buggy tags. Existing buggy tags unfortunately remain and nothing can be done about it. But it seems that at least the ones on en.wp disappeared somehow.
Screenshot for future reference.
MediaWiki accepts the following DTD declarations: (from UploadBase::checkSvgExternalDTD())
Fri, Jun 23
After the fixes:
The missing icon was fixed in acde3756. Have we really not done an OOjs UI release with that?
I'm actually not sure if it's https://gerrit.wikimedia.org/r/#/c/350260/. The longer I look at this code, the crazier it seems. Right now I don't understand how it ever could fit there at all.
Because we can't always automatically determine which is the right overlay. The value depends on where you're doing to insert the widget (in a dialog or not, and which dialog), and we don't know that when the widget is being created.
Also, I feel I need to explain the confusing 12.8px and 14px sizes. To be clear, no one is proposing changing the size of the actual text. We only want to make the icons approximately 2 pixels smaller. :)
Anyway, my point is that someone should be working on T97631 instead, so that we can display our existing icons at their natural size inside our existing website without changing font sizes all over the place manually.
I mentioned it to @Volker_E once and he said this is intentional / unavoidable limitation of CSS on <select> elements. I don't recall why exactly, I think it's something to do with hiding the browser native arrow on the dropdown.
Yes. I gave it a +1 because it is an improvement to the interface. But it is adding more technical debt.
Thu, Jun 22
RequestContext::getMain()->getTitle() clearly does not return a Title, otherwise we would not be getting the fatal in the title of this task?
So actually, due to different licenses, copy-pasting jquery.accessKeyLabel code into OOjs UI would be a copyright violation (and parts of this code are like ten years old so contacting the authors to relicense it would be difficult). Reimplementing it from scratch seems like a waste of effort. I'm just going to make OOjs UI call into jquery.accessKeyLabel if it's available.
Sure, that works.
They seem to work fine together for me – can you elaborate / file a bug?
Oh sorry, I see you found this out, I didn't refresh the page to see your comment :)
You can manually return a rejected promise if you require this behavior. This works with both jQuery 1 and 3.
You can also view your watchlist or recent changes in either mode without changing your preferences by using URL parameters, like this:
All perfectionists in the world cry tears of blood. WMF Design team should probably too, given their section on alignment :-)
Wed, Jun 21
No, the other patch needs to be merged.
Tue, Jun 20
This is a limitation of the CSS model we have to work with. You can work around this by passing an $overlay config option to the DropdownWidget, allowing its dropdown to render outside of the bounding box of the dialog. See here: https://www.mediawiki.org/wiki/OOjs_UI/Concepts#Overlays
Whatever the problem was, it works these days. :)
Mon, Jun 19
This should be fixed after f8b8d2689d57042401d7b25cac29a45ea77e58c4.
The patch is just a workaround to fix this for the edit summary field, which already gets infused by core code. I'm not sure what would be the proper way to make the two features work together. Possibly we should merge the functionality of jquery.accessKeyLabel into OOjs UI's AccessKeyedElement.
This is a regression from badb35947c222850ffe801a0b480e83c0f6f5818 (OOjs UI v0.21.3).
I don't think this patch can be merged. This is a very large change to the design of the skin. I would recommend that you turn this into a new skin, based on Vector (http://blog.redwerks.org/2012/02/28/mediawiki-subskin-tutorial/). I think users of existing wikis (including Wikimedia wikis', but not only) would be unhappy to see the interface changed suddenly after updating the skin.
I can't reproduce this.
I'm assuming this was with the visual editor (or the new wikitext editor), correct?
259 users on frwiki (the query took about 20 minutes), out of 23284 "active" (the query took about 5 minutes).
A more limited form of this has been inplemented in T147951 – you can use e.g. searchfilters=incategory:Blah to append arbitrary filters to the user's search query.
Sat, Jun 17
Fri, Jun 16
The query below gives the result as 21 "active" users using the old toolbar on English Wikisource. This is with a very loose definition of active – at least 1 edit in last 30 days; we have a better metric for this somewhere but I don't recall where. By the same metric, there are 557 active users in total. For English Wikipedia, the numbers are 1576 "active" users out of 218154 total. (Again, this is a very loose definition of "active" and the number of users who would actually care or notice is probably lower.)
Thu, Jun 15