| RoySmith | |
| Sep 26 2022, 5:11 PM |
| F35535126: Screen Shot 2022-09-26 at 1.05.12 PM.png | |
| Sep 26 2022, 5:11 PM |
| F35535124: Screen Shot 2022-09-26 at 1.05.24 PM.png | |
| Sep 26 2022, 5:11 PM |
Go to https://en.wikipedia.org/wiki/Wikipedia_talk:Requests_for_comment/Responder_role#Can_we_not_do_this_again in both Vector 2022 and legacy vector.
In the legacy skin, the resulting page is scrolled down so the "Can we not do this again" section is visible. In the 2022 skin, the scroll is left at the very top. See attached screenshots.
Chrome Version 105.0.5195.125 (Official Build) (x86_64)
MacOS Monterey 12.5.1 (21G83)
I can neither reproduce in Firefox 105 nor Chromium 105. Does this still happen on https://en.wikipedia.org/wiki/Wikipedia_talk:Requests_for_comment/Responder_role?useskin=vector-2022&safemode=1#Can_we_not_do_this_again with safemode? See https://www.mediawiki.org/wiki/Help:Locating_broken_scripts
It still happens with an empty common.js (https://en.wikipedia.org/w/index.php?title=User:RoySmith/common.js&oldid=1112513431) but safemode=1 makes the problem go away.
I haven't gone through all the gadgets yet because that's kind of a painful process.
Wow, this is weird. It was starting to look like having spaces in the fragment was the problem, but I can't quite reproduce that either. In any case, these two URLs work properly:
But both of these exhibit the incorrect behavior:
In these later two cases, I can see it transiently scroll to the correct place in the page, then scroll away again after a fraction of a second. I can't quite put my finger on it, but it smells like this has to do with whether the section heading is high enough in the TOC that it's visible when the TOC is scrolled to the default position.
Oh, yeah, that's it. If I make my font small enough that the entire TOC fits on the screen without scrolling, every one of these URLs (including the one in the original report) works fine.
This appears to be triggered by Preferences / Gadgets / Change UTC-based times and dates, such as those used in signatures, to be relative to local time.
I object to this being closed as "invalid". There are lots of gadgets which have been in widespread use for a long time which do similar kinds of DOM manipulation. If the skin is going to break all of them, that's a problem with the skin.
It's invalid regarding the Vector 2022 codebase only. If gadgets turn out to not be robust enough, gadgets need to be fixed.
Can the Vector 2022 team publish a spec describing what types of DOM manipulations are allowed, and/or the appropriate hooks to perform them, and provide assistance in figuring out what went wrong in this particular case? In the ongoing RFC, it was stated that the team has committed to "Working in collaboration with gadget creators or other interested developers to fix gadgets by providing support and guidance. This could include anything from advising on why a certain gadget does not work to providing specific code snippets as fix suggestions". Closing a bug report on a incompatibility with a gadget as "invalid" does not seem like it is living up to that commitment.
This gadget has been annoying me for some time so I'm going to spend some time tracking it down and writing on its talk page.
In a nutshell the team responsible for Vector 2022 do not usually maintain gadgets and since gadgets are often made with certain skins in mind they sometimes break despite our best efforts to avoid that. In this case the gadget is not working on Vector legacy which has been frozen for some time so it's likely a change in the gadget at fault here or an incompatibility with the recent changes to talk pages.
We can provide advice but given the amount of gadgets in our ecosystem our commitment is usually to helping gadget developers coming to us with questions concerning their gadgets. In this case it seems we have to identify the gadget, analyze the problem, and reach out to the gadget developer. Usually we prefer it working in the other direction (wiki discussion first then reaching out to us for help if that's not providing resolution).
We currently don't officially support any DOM manipulations. Although we recognize these are widespread so are careful with our changes (although in future hope to move away from those)
https://m.mediawiki.org/wiki/ResourceLoader/Core_modules is probably best article to document what is actually officially supported.
@RoySmith you might be interested in https://m.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy which I've been slowly pushing forward as right now it may surprise you to learn that there is no official agreement between gadget developers and mediawiki code contributors about how to work together. It relies a lot on an informal contract which I'd like to get away from. It also expands on what is currently supported :)
I see in T318600 <https://phabricator.wikimedia.org/T318600> it was stated that "We currently don't officially support any DOM manipulations". This is an untenable position. There are many add-on scripts which perform DOM manipulation. You can't just break all of those.
To do the opposite would also be untenable for skin developers as sometimes we need to change the IDs / classes or HTML structure of pages and if we have to support DOM manipulations, it means skins can't make any changes to themselves. Fir example there is no way to change an ID of an element in a backwards compatible way
mw.util.$content is a good example of an API that provides access to the content and is resilient to changes by skin developers. We're trying to move more in that direction to have a clearer separation that serves both parties.