Fixes something that isn't broken

AceEditor doesn’t seem very performant on bigger pages, to the point where you have to turn it off. Per https://github.com/ajaxorg/ace/issues/2164#issuecomment-1683586029 the accessibility in Ace is also optional, and I’m not sure we have that option turned on. So it’s not exactly going to be for nothing if we manage to switch to CodeMirror.

TemplateData uses tabs exclusively, as does CodeEditor, and I don’t think there are that many other instances where such spacing is present in wikitext pages. indentString doc seems to suggest that if you set indentUnit to \t and there isn’t sufficient space (not 4 spaces) to form a tab, it would be using spaces. Config solution is fine for the future, but CodeMirror still should use tabs by default given its current scope.

Automatic indentation detection is not yet available from CodeMirror, and the indentUnit config has to be consistent throughout one document. Therefore, if we prescribe one tab as the default, then the editor will always indent with tabs even where spaces are used. One possible solution is to add this config to the future preferences panel (T359498) so that the user can choose appropriate indentUnit.

Whatever is easier to implement in CodeMirror (I assume it is just a config option). Currently it inserts spaces even where tabs are used. Tabs are preferable as a default for accessibility reasons:
https://adamtuttle.codes/blog/2021/tabs-vs-spaces-its-an-accessibility-issue/

Are you requesting automatic indentation detection or literally tabs?

Noting this bug that @Izno informed me of:

In T371436#10142944, @Quiddity wrote:

Is this ready to be re-added to Tech News this week? (Prior removal diff for reuse). Thanks!

Thanks @Samwilson! I think switching to a central dialog could be a solution but let's see if T364664 changes anything. I will check with the huwiki community after it is deployed and report back.

There have been requests to also change the position of the notification, and instead have it be a dialog in the middle of the page so it's easier to see. Do you think that'd be a good change?

or such obvious errors would have been fixed immediately

I've made this task public as it isn't a security issue and might benefit from more eyes on it. LoginNotify is technically maintained by Community-Tech these days, though I don't believe it's a top priority for their team and hasn't been actively developed aside from very minor maintenace updates in some time. I'd note that there are also user prefs available to disable various LoginNotify communications for those users that find them unhelpful:

Sorry, this is quite valid, and I hesitate to believe these issues are sufficiently covered in existing bug reports, or such obvious errors would have been fixed immediately, most of it is not difficult. "Up to one year" is nitpicking, seeing as this stuff isn't flexible. These expiring cookies get a specific end date, it isn't fuzzy, computers are specific. I don't think it said "up to", but if it does that's intentional lying unless it actually IS a year (no matter the precise wording, sorry). All the same arguments go to the place that said 180 days. If that's not the specific length - it was worded like it is - that's also a lie. If it's accurate, the checkbox is a lie. SOMETHING needs fixing, only devs who can see the code can confirm the actual truth.

The checkbox says it'll keep me logged in for a year.

Is there anything I can work on as a non-tech person, to help move this idea forward? Or are there meaningful subtasks, so that we can perhaps break it up into easier pieces?

I felt this counted as Security since security is the reason we get logged out, and security is the reason for the email. Both are to protect the security of Wikipedia accounts. If there was no need to secure against malicious activity, there's no need to log us out, this is to make sure a malicious party doesn't find us logged in and do things in our name. And the email is to alert us of a login, in case someone else managed to login as us, then same thing, could make malicious edits in our name. Also, these security features making mistakes suggests potential for a minor security breach, if this isn't working right there might be something to exploit in this. As sbassett stated I can't see the exploit, but I'm not someone who makes a habit of using exploits, so that doesn't mean there isn't one. Feels better to fix it to be sure.

In T375989#10187181, @Aklapper wrote:

Hi @Niceguy169, thanks for taking the time to report this! Could you elaborate what makes this a security issue?

Hi @Niceguy169, thanks for taking the time to report this! Could you elaborate what makes this a security issue?

Change #1071644 merged by jenkins-bot:

[mediawiki/core@master] TargetActiveBlocks/TargetBlockLog: Populate table components with blocks

https://gerrit.wikimedia.org/r/1071644

Thanks all, I set the target date of the task to first of November 2024.

Done and deployed.

samwilson merged https://gitlab.wikimedia.org/repos/commtech/autosuggest-sitelink/-/merge_requests/60

We're also happy to make this change ourselves with review help from CommTech :) I don't believe we've used this new component feature in production yet.

@MusikAnimal Not urgent, but putting this on your radar. I don't think it's necessary as part of the initial goal of just migrating the existing Special:Block page to Vue+Codex, but you might want to make this swap when implementing the actual Multiblocks functionality.

Ok, thanks @Samwilson. I'm going to move this task back to our quarterly planning column where it will be re-reviewed during our next scheduled planning session (October 1st, 2024). I'll note that we'll plan to complete this review sometime within the month of October 2024.

I don't think we'll get it done by the 24th (which is already today in some parts of the world). But if we can aim for a date within the first couple of weeks of next quarter that sounds great, I think! We're making progress now with moving all the functionality from the gadget, so hopefully the code will be representative of the completed extension (e.g. it'll show what we're aiming for with the special pages, database tables, parser functions, font-end access of remote APIs, etc.). Perhaps not perfect, and we'll be continuing to work on it, but the skeleton (and a fair bit of the detail) will be done.

In T375338#10166018, @Samwilson wrote:

Yep this sounds annoying! And circular sitelinks should definitely be avoided. :)

So it shouldn't show in the mainspace or Property or Lexeme namespaces, but I guess it should still show on other Wikidata namespaces shouldn't it?

samwilson opened https://gitlab.wikimedia.org/repos/commtech/autosuggest-sitelink/-/merge_requests/60

Yep this sounds annoying! And circular sitelinks should definitely be avoided. :)