User talk:ESanders (WMF)

Welcome to Meta![edit]

Hello, ESanders (WMF). Welcome to the Wikimedia Meta-Wiki! This website is for coordinating and discussing all Wikimedia projects. You may find it useful to read our policy page. If you are interested in doing translations, visit Meta:Babylon. You can also leave a note on Meta:Babel or Wikimedia Forum if you need help with something (please read the instructions at the top of the page before posting there). Happy editing!

--Liuxinyu970226 (talk) 01:18, 5 December 2015 (UTC)[reply]

2016 Community Wishlist Survey[edit]

Hi,

You’re getting this message because you participated in the 2015 Community Wishlist Survey and we want to make sure you don't miss it this year – or at least can make the conscious choice to ignore if it you want to. The 2015 survey decided what the Community Tech team should work on during 2016. It was also the focus of Wikimedia hackathons and work by other developers. You can see the status of wishes from the 2015 wishlist at 2015 Community Wishlist Survey/Results.

The 2016 Community Wishlist Survey is now open for wishes. You can create proposals until November 20. You will be able to vote on which wishes you think are best or most important between November 28 and December 12. /Johan (WMF) (talk) via MediaWiki message delivery (talk) 11:17, 14 November 2016 (UTC)[reply]

Regarding Special:Diff/21167657[edit]

Hi Ed. I saw you removed this line from my global.js. I have a couple notes:

What is the current method for enabling discussion tools globally? Is it on by default?
When editing others' userspace pages, it is customary to ask the other person to do it rather than do it yourself, except in emergencies. This is the case especially when you do so using Foundation-granted permissions to do so. If doing so directly, it is generally considered necessary to give a notification. I understand that it may seem like an innocuous technical change to you, and it in fact may be, but it is useful to explain this, if only through a templated notice; after all, one's userspace is highly personal. In this volunteer project respecting these norms is the courteous thing to do.

Thank you for your work on the tool; I appreciate all you have done to improve our projects. Best, KevinL (aka L235 · t) 08:24, 2 March 2021 (UTC)[reply]

In fact, it seems that discussion tools no longer load for me on this wiki, and I cannot see how to re-enable them. Best, KevinL (aka L235 · t) 08:30, 2 March 2021 (UTC)[reply]

@L235: On this wiki, the reply tool is enabled as a Beta Feature, under Special:Preferences#mw-prefsection-betafeatures. Once you have enabled the Beta Feature, make sure the reply tool is enabled in Special:Preferences#mw-prefsection-editing-discussion. The user script hack will enable the tool on wikis where it isn't a Beta Feature, or enabled by default. Thanks, ESanders (WMF) (talk) 12:38, 4 March 2021 (UTC)[reply]

Ed, you did remove it from my global.js file, which applies on every WMF project – not just meta. Also, if it isn't an inconvenience, I'd appreciate an acknowledgement of my second note above and either (1) a commitment to ask (or at minimum leave notifications) when making similar changes in the future or (2) an invitation to further dialogue on the question. Best, KevinL (aka L235 · t) 20:29, 4 March 2021 (UTC)[reply]

@L235: You said that the tool no longer works on this wiki. For that you should use the Beta Feature. Has the tool stopped working on any wiki that doesn't have the Beta Feature? I would be very surprised if my change resulted in any change at your end because the line of code I removed should be a no-op since the wmf30 release. If that is the case I can look into it for you.

To explicitly answer (1) - the hack that is on your user page is the "correct" way to enable discussion tools globally (although it is just a temporary hack). No, discussion tools are not enabled by default on most wikis (except Hungarian, Czech & Arabic Wikipedias).

To address (2) - I try to use my judgement based on the complexity of the change, and the location of the code. In this particular case the two lines of code were ones I wrote myself and had been cloned to other pages. I however note and respect your objection and will ensure I notify you if I ever need to modify your user scripts in future.

To be clear: the edit should have resulted in no change to where you see the tool, it was purely cleaning up dead code. Regards, ESanders (WMF) (talk) 20:56, 4 March 2021 (UTC)[reply]

Commentlink.js[edit]

Hello!

I was recently introduced to you script about comment links. I really enjoy it. I was thinking if maybe it could be changed so that the link button only appears on hover above the specific comment it is supporting. Would that be achievable? Would that be an overall accepted improvement? Do you foresee any downsides I might be currently overlooking? I think it would make it easier to not clutter the page. - Klein Muçi (talk) 12:22, 10 June 2022 (UTC)[reply]

You may have some difficulty knowing if the comment has been hovered as comments can span multiple nodes and depths of the DOM, and do not have a single wrapper. Also you would need to leave space for the [link] to appear otherwise it could cause the text to wrap and other content to jump around as you hover different comments. ESanders (WMF) (talk) 15:39, 10 June 2022 (UTC)[reply]

Hmm... I see... It's been a while I've asked for the ability to highlight individual comments on hover and I was thinking that this kind of function could be coupled with showing a [link] below them but apparently it's not that easy. - Klein Muçi (talk) 17:02, 10 June 2022 (UTC)[reply]

Commentlinks-v1[edit]

Hello! Lately the aforementioned script has started showing a JS error in every page that I load. I am aware that it is an old version but I thought maybe you'd be interested anyway in knowing about it (I can copy-paste the error that I get) and MAYBE it can be easily fixed? — Klein Muçi (talk) 18:11, 10 December 2022 (UTC)[reply]

I've fixed it, although the old version of the tool will not be compatible with the new visual enhancements to the page, as it uses a reply button, rather than a link. I probably won't update it to support that. ESanders (WMF) (talk) 16:49, 12 December 2022 (UTC)[reply]

Not working on archived pages[edit]

Could you please make the wonderful script give me links on archived pages (pages transcluding w:en:Template:Aan)? WhatamIdoing (talk) 21:01, 22 July 2023 (UTC)[reply]

Fixed. ESanders (WMF) (talk) 11:55, 23 July 2023 (UTC)[reply]

･:* ﾟ Thank you! ﾟ*:･ WhatamIdoing (talk) 19:02, 24 July 2023 (UTC)[reply]

Commentlinks not working in Firefox[edit]

Hey. I've been using commentlinks over on enwiki for a week or two now, and about an hourish ago it stopped working. But only in Firefox (v115.0.2), and only sometimes. Occasionally if I load a talk page it will work, but if I reload the same page to fetch updated comments it stops. It works as expected on Chrome however. There's nothing obvious I can see in Firefox's developer tools for why it's not working, no errors or warnings popping up in the console for it, and it's definitely being successfully fetched by the browser. It's just silently failing and not adding either the custom CSS for the timestamp links, nor the links themselves.

Sorry to just give you a report that "it's broke", but I'm genuinely stumped as to why it's not working. Happy to help debug though if you can't replicate it. Just ping me on replies please, I don't often open meta, so will likely miss any replies that aren't pings. Thanks. Sideswipe9th (talk) 20:34, 24 July 2023 (UTC)[reply]

I can't reproduce in Firefox. Are there any particular pages where it is happening? ESanders (WMF) (talk) 15:06, 25 July 2023 (UTC)[reply]

No specific pages I'm afraid, it seems to affect all pages where editors sign comments. To rule out if it was something specific to my browser's setup (eg extensions) I've tested a clean install of Firefox in a virtual machine, and the same thing happens. The only thing I've not tried yet is disabling all the other scripts I use on enwiki (common.js, vector-2022.js) to see if there's an incompatibility with another script I use, which I'll try now. Sideswipe9th (talk) 15:49, 25 July 2023 (UTC)[reply]

Ok, disabled every script in my common.js and vector-2022.js, along with any custom CSS I was using (just to be through). I also decided to try this on testwiki, no gadgets enabled and the only custom script being commentlinks. The same issue is happening, in the current version of Firefox (v115.0.2), commentlinks doesn't work, and in any other browser it works. Sideswipe9th (talk) 16:05, 25 July 2023 (UTC)[reply]

Are there any errors in the console? ESanders (WMF) (talk) 17:43, 25 July 2023 (UTC)[reply]

Using my enwiki user talk page, there are no errors, two warnings, and 19 info messages. The two warnings are about something loading the deprecated jquery.ui module (the log takes me to the assert for the deprecation message, which has been minified so not easily readable), and the page using a non-standard "zoom" property. Of the 19 info messages, one seems relevant:

Referrer Policy: Ignoring the less restricted referrer policy “origin-when-cross-origin” for the cross-site request: https://meta.wikimedia.org/w/index.php?title=User:ESanders_(WMF)/commentlinks.js&action=raw&ctype=text/javascript

There's 16 similar entries for other several other scripts coming from the meta, commons, upload wikimedia subdomains, and wmflabs, and for some images that are coming from upload.wikimedia. The two other info messages are for Who Wrote That? successfully loading. Sideswipe9th (talk) 20:35, 25 July 2023 (UTC)[reply]

I think I've figured it out. It's Firefox's Enhanced Tracking Protection. As soon as I disable that and reload the page, commentlinks starts working successfully. If I enable it again and reload, commentlinks breaks. Sideswipe9th (talk) 20:37, 25 July 2023 (UTC)[reply]

Interesting. If you load the page with it enabled, and click on the shield, does it list anything has being blocked? I also have it enabled and still can't reproduce. ESanders (WMF) (talk) 11:19, 26 July 2023 (UTC)[reply]

Strangely no, apart from the overall number of protections it doesn't list anything specific as being blocked. I do have it set to the custom level though, with cookies set to "cross-site tracking cookies, and isolate other cross-site cookies", tracking content in private windows, cryptominers, and fingerprinters all set to blocked.

Running through the options, it seems to be the cookies setting that's breaking it, as if I change that to just "cross-site tracking cookies" it loads fine. It's only whenever its set to "cross-site tracking cookies, and isolate other cross-site cookies", or one of the two explicit "may cause websites to break" options that it fails to load. Sideswipe9th (talk) 16:51, 26 July 2023 (UTC)[reply]

Which might explain why it's working fine on meta, and (just tested) commons, as those are on the same domain; wikimedia, whereas enwiki is on a different domain. Not sure why it's isolating a raw javascript source though as though a cookie is involved? Sideswipe9th (talk) 16:56, 26 July 2023 (UTC)[reply]

Sounds like there might be a Firefox bug that could be filed then. Not much I can do from my end, although hopefully this functionality will be available by default in the near future and so there will be no need for this user script. ESanders (WMF) (talk) 14:08, 27 July 2023 (UTC)[reply]

Sounds like there might be a Firefox bug that could be filed then Maybe, though I'm not sure how I'd frame it to them. Is that something you might be able to handle?

hopefully this functionality will be available by default in the near future That would be pretty cool! Sideswipe9th (talk) 14:28, 27 July 2023 (UTC)[reply]