Page MenuHomePhabricator
Search Advanced Search
    • Task
    The watchlist has a set of tabs at the top of the page like so: {F34923641} In Minerva we want to style like so: {F34923639} To support this several things are needed # Acceptance criteria [ ] Use the mediawiki.interface.helpers.styles module to provide the parentheses and pipes [] Add classes to all the elements in the subtitle to allow them to be distinguished [] Add a class to the selected tab.
    • Task
    Currently, you can filter Special:RecentChanges/Watchlist by `userExpLevel`. However, for the API:RecentChanges module, you only have access to the the `rcshow` filter, which does not include, say, `newcomer`. It would be good if any Special:RecentChanges/Watchlist URL could map to an equivalent API query. **Use case(s)**: Allowing API queries to produce the same (or at least similar) result sets to those available in the Special:RecentChanges/Watchlist pages. For example in "popups" gadgets when hovering over links to RC/WL pages.
    • Task
    ==== Problem Currently the empty state of the Watchlist page on Desktop doesn't provide any explanation or introduction to what the Watchlist is, which makes it hard for newcomers to start using it as an aid to their editing process. {F34724729} ==== User job story As a person with a new account who has no watched pages **When I** navigate to the Watchlist page, **I want** to understand what the watchlist is for... **So that** I can start using it for tracking articles of interest. ==== Proposed solution * Provide an empty state illustration and introduction text on desktop. * Revise the empty state on Mobile to be consistent across platforms (see also T222871) Designs TBC
    • Task
    **Feature summary** (what you would like to be able to do and where): On Special:Watchlist, when "Live updates" are enabled, the number of new changes should be indicated in the document title. That is, the title should change from Watchlist - Wikipedia to (1) Watchlist - Wikipedia if there is 1 new change that appeared from a live update. **Benefits** (why should this be implemented?): - Even when working on something else in another tab, the user gets to know about new changes. This is more or less standard behaviour across the web to indicate new notifications/messages.
    • Task
    Per codesearch, the only place that the `mediawiki.watchstar.widgets` ResourceLoader module is used is as a run-time dependency of the `mediawiki.page.watch.ajax` module (loaded via mw.loader.load and mw.loader.using when needed if watchlist expiry is enabled). I propose that the widget be merged into the watch module, unless there are plans to use it elsewhere. The widget was originally introduced to be used in the watch module, {6224ffd03ccf31b80662704da5ee47a11751e310} / {T249259}, and I couldn't find references to any other uses in the past. This could cause a minor performance hit if additional loading is needed for the dependencies of the widget that aren't being loaded immediately for the overall watch button. If this is an issue, we can make is so that the dependencies of the widget still only get loaded when needed by putting them in the mw.loader.load / .using calls instead of the widget itself, and having the widget code not be run until the dependencies are loaded.
    • Task
    It is annoying to see edits on the watchlist again that you've already seen because you got a notification about them (because you were mentioned, it's your own talk page, you subscribed to a topic using DiscussionTools, etc.) What if the watchlist had a filter to exclude edits that also caused a notification to be sent to you?
    • Task
    Today Ī̲ stumbled upon a bizarre link https://www.wikidata.org/w/index.php?title=Property:P4575&curid=44760560&diff=1470987750&oldid=1470987750&diffmode=source in the watchlist (in words: both diff and oldid point to the latest revision) instead of the expected diff spanning two consecutive edits. The link text misleadingly says “2 changes”, but the associated mw-diff-bytes (appropriately) shows “0”. At https://www.wikidata.org/wiki/User:Incnis_Mrsi/Property:P4575 you can see HTML source (with minor changes pertaining to MediaWiki rendering). This doesn’t look like a browser glitch. Why Special:Watchlist compares the last revision with itself?
    • Task
    [I've searched through Phabricator and can't find anything like this, but this is at tricky search. The closest I found is T208868, which is clearly a very different bug. If this is already fixed, great, but otherwise...] In a two-week-old MediaWiki 1.35 installed under Ubuntu 20.04, with Firefox as the client: Unchecking the user preference "Group changes by page in recent changes and watchlist" is magically set back to checked when "Recent Changes" is loaded, but ONLY IF "Use non-JavaScript interface" is not checked. As a result, RC lists are always grouped. This is true even if "Expand watchlist to show all changes, not just the most recent" is already checked. If "Use non-JavaScript interface" is checked, -then- it is possible to uncheck "Group changes by page in recent changes and watchlist", reload Recent Changes, and have the setting persist. Once the setting has survived at least one RC reload, it is then possible to uncheck "Use non-JavaScript interface", reload RC, and it stays ungrouped and "Group changes by page in recent changes and watchlist" stays unchecked. I originally thought this might be my preferences somehow not getting saved, because I would uncheck "Group changes by page in recent changes and watchlist" and would find it magically checked again after I tested whether it had affected RC. But I could load other pages, and I could also either hop around in the Preferences tab, or reload the page, or load it fresh in a separate browser tab, and the unchecked setting would stay unchecked, -until- I reloaded Recent Changes---whereupon Group was magically checked again as soon as I reloaded the Preferences page. And other preferences -do- get saved normally, so that rules out (for example) some weird 302 POST problem because I'm using shortened URLs---and, having figured out the workaround where I turn off the JS interface and my grouping preference then get saved, it's clear that prefs are really being saved. If someone needs me to reproduce this, I have a copy of the database from that time and could if necessary reload it. I would rather -not- have to try to reproduce this in 1.36; I'm running 1.35 because it's LTS and I don't want to be on an upgrade treadmill with a non-LTS release. (It would be a lot of work to install 1.36 in parallel.) Note that the client side of this was Ubuntu 14.04 running an old (66.0.3) version of Firefox. It's got NoScript running but I've told it to trust scripts on my own wiki. I could attempt to reproduce this in 20.04 with the current version of Firefox without much trouble.
    • Task
    WatchedItemStore writes instances of MapCacheLRU to $this->cache, which is a BagOStuff. MapCacheLRU is not safely serializable. Either MapCacheLRU has to become JSONUnserializable, or WatchedItemStore should cache a plain list rather than an object.
    • Task
    `mw-watchlink-notification` doesn't seem to exist any more. The whole notifications are now encapsulated in `#mw-notification-area`.
    • Task
    I get a hundreds of e-mails from SchlurcherBot, even though I entered the preferences on my user page under notification as an muted user. How else can I prevent this? I would be grateful for a solution.
    • Task
    It seems like logged actions from Wikidata that are marked as bot are treated as non-bot actions when I see my watchlist on English Wikipedia. It appears that the problem happens with logged actions only, not edits. With [Latest revision][Page creations][Logged actions][Wikidata edits][Human (not bot)] turned on, my watchlist has this line (which is not an expected behavior): ``` 2021-03-05 (diff | hist) . . Dm Early modern human (Q15978631); 17:55:07 . . MsynABot (talk | contribs) (Protected "Q15978631": Highly used item: to be indefinitely semi-protected per Wikidata:Page protection policy#Highly used items; please use Template:Edit request on the item talk page if you cannot edit this item ([Edit=Allow only autoconfirmed users] (indefinite))) ``` For comparison, with [Latest revision][Page creations][Logged actions][Wikidata edits][Bot] turned on, my watchlist has this line (which *is* an expected behavior): ``` 2021-03-09 (diff | hist) . . Dmb Versailles, Yvelines (Q621); 10:55:35 . . AVMbot (talk | contribs) (‎Changed claim: Property:P1082: 85,862, Add France 2018 population; ‎Changed an entity: Add France 2018 population) ``` Ideally, both should be shown only when [Bot] is turned on as a watchlist filter. On my Wikidata watchlist, both are treated as a bot edit/action. Link to the edit I gave as an example above: https://www.wikidata.org/w/index.php?title=Q621&curid=906&diff=1378517781&oldid=1378517766 Link to the logged action I gave as an example above: https://www.wikidata.org/w/index.php?title=Special:Log&logid=664667041 https://www.wikidata.org/w/index.php?title=Q15978631&diff=1375907918&oldid=1367496643 **See also:** {T246746} about bot edits instead of actions.
    • Task
    @MisterSynergy started running a bot task on Wikidata today that protects high visibility items on Wikidata. The changes in protection levels appear on English Wikipedia watchlists (and presumably also in other languages) e.g., as: "(diff | hist) . . Dm Template:Cite Q/testcases (Q6654); 18:04 . . MsynABot (talk | contribs) (Protected "Q6654": Highly used item: to be indefinitely semi-protected per Wikidata:Page protection policy#Highly used items; please use Template:Edit request on the item talk page if you cannot edit this item ([Edit=Allow only autoconfirmed users] (indefinite)))" {F34138689} I'm not sure that such notices are relevant on enwp, since they don't change the content of the articles that are affected, and they could be confused with protection of the articles themselves. Should these notices appear, or could they be suppressed? EDIT: Some of the log items in concern on the Wikidata side: * https://www.wikidata.org/wiki/Special:Redirect/logid/664668358 * https://www.wikidata.org/wiki/Special:Redirect/logid/664668357 * https://www.wikidata.org/wiki/Special:Redirect/logid/664668356
    • Task
    This task is about creating ways for editors to write rules that determine what talk page activity they are notified about. This idea is prompted by the idea @Sdkb shared on mediawiki.org [here](https://www.mediawiki.org/w/index.php?title=Topic:W3c084ihivgkm9vt&topic_showPostId=w3c4ps7qjbtfdr4h#flow-post-w3c4ps7qjbtfdr4h): > ...sometimes, there are pages where I might want to pay attention only to future sections that meet or exclude particular criteria. For instance, at ITN nominations, some editors might want to only watchlist sections that are not recent deaths, so it'd be really powerful to be able to tell the software "watchlist new sections here if they don't contain `|recent death = yes`"
    • Task
    The watchlist links `diff` and `hist` are mis-nested HTML: they are a `<DIV>` within a `<SPAN>`: ```lang=html <span class="mw-changeslist-line-inner" data-target-page="Wikisource:Scriptorium"> <div class="mw-changeslist-links"> ....links </div> .... </span> ``` This is invalid HTML, since it's a block element inside an inline one. The W3C validator reports this as an Error. {F34114088}
    • Task
    Like opening the [[https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E7%94%B5%E5%AD%90%E6%B8%B8%E6%88%8F%E4%B8%93%E9%A2%98/%E4%BB%BB%E5%8A%A1%E5%88%97%E8%A1%A8&curid=4684835&diff=64021391&oldid=43530210 |diff]] will not remove the change from my watchlist unless I viewing the page. My watchlist filter settings include "unviewed changes". There is no unviewed highlight style in the history page of this page. I encounter it more often because of using https://en.wikipedia.org/wiki/User:Evad37/Watchlist-openUnread. This also seems to happen when a page has been changed to a redirect.
    • Task
    Steps to Reproduce: # Goto https://de.wikipedia.org/wiki/Spezial:Beobachtungsliste_bearbeiten # Check the first two entries # Delete them with the Button "Delete Entries" (german: "Einträge entfernen") # Wait for the confirmation page # Go back in your browser to the previous page # Check any unchecked entry # Delete them with the Button "Delete Entries" (german: "Einträge entfernen") Actual Results: - As the previous checkboxes have not been resetted 3 entries are removed from the watchlist Expected Results: - Checkboxes must reset to avoid unintentional removal of entries. In this case I expect that only one entry is removed.
    • Task
    I implemented a way to get a Watchlist that does not require you to waste lots of time. This is how I discovered that when you have the Watchlist open in a tab it sends a GET request every second or so: it's continually pulling even if "Live updates" is disabled. This is also how it displays the "View new changes since..." note at the top when things have changed. I don't need or want this constant pulling when having a Watchlist tab open and it doesn't work with my method to get a working Watchlist, which is why I'd like to disable it. It only drains my computer/network's and MediaWiki servers' resources and has no advantage while having some disadvantages in my case. However, I couldn't find any setting to disable it in the preferences and [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#How_to_prevent_constant_pulling_%28GET_requests%29_of_the_Watchlist%3F | other users didn't know of a way to prevent this either ]]. You can check it like this: * Open your Watchlist * Press `F12` in Firefox * Go to the Network tab in that new window * There should be a new GET request every 2 seconds or so if the JavaScript version of the Watchlist is used (no continous pulling for the old non-JS version) Could you please add an option to the preferences and/or the Watchlist page to toggle this auto-refreshing?
    • Task
    Open this link and inspect any collapsed lines. https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidepageedits=1&hidenewpages=1&hideWikibase=1&hidelog=1&enhanced=1&urlversion=2 Example: - 22:24 [[https://en.wikipedia.org/wiki/Category:Midtown_Manhattan|Category:Midtown Manhattan]] (2 changes) . . [ [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] (2×) ] -- [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594781|22:24]] . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/3_Park_Avenue|3 Park Avenue]] removed from category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/3_Park_Avenue|this page is included within other pages]])// -- [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594739|22:23]] . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/Lexington_Avenue|Lexington Avenue]] added to category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/Lexington_Avenue|this page is included within other pages]])// Notice "22:23" on the third line is linked [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594739|here]], with `curid=9288855`, which is for [[https://en.wikipedia.org/wiki/3_Park_Avenue|3 Park Avenue]], not [[https://en.wikipedia.org/wiki/Lexington_Avenue|Lexington Avenue]]. In any group of category changes, the `curid` for the page on the first line is mistakenly being used on all the rest of the collapsed lines. Though this can't be reproduced in markup here, the `title` attributes (tooltips) of the timestamps are also wrong: they're set to the name of the category, not the linked pages themselves.
    • Task
    Open this link and inspect any collapsed lines. https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidepageedits=1&hidenewpages=1&hideWikibase=1&hidelog=1&enhanced=1&urlversion=2 Example: - 22:24 [[https://en.wikipedia.org/wiki/Category:Midtown_Manhattan|Category:Midtown Manhattan]] (2 changes) . . [ [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] (2×) ] -- [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594781|22:24]] . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/3_Park_Avenue|3 Park Avenue]] removed from category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/3_Park_Avenue|this page is included within other pages]])// -- [[https://en.wikipedia.org/w/index.php?title=Category:Midtown_Manhattan&curid=9288855&oldid=995594739|22:23]] . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/Lexington_Avenue|Lexington Avenue]] added to category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/Lexington_Avenue|this page is included within other pages]])// Compare it to grouped lines for ordinary edits, and notice "(cur | prev)" are missing even though diff links for non-grouped category changes are available at the end of each line. Also there are no history links, and `title` and `curid` in the permalinks (timestamps) are wrong (`title` is that of the category and the second `curid` is same as the first—this part being tracked as T270774). So it should be more like: - 22:24 [[https://en.wikipedia.org/wiki/Category:Midtown_Manhattan|Category:Midtown Manhattan]] (2 changes) . . [ [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] (2×) ] -- [[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=9288855&oldid=995594781|22:24]] ([[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=9288855&diff=0&oldid=995594781|cur]] | [[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=9288855&diff=995594781&oldid=995594692|prev]]) . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/3_Park_Avenue|3 Park Avenue]] removed from category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/3_Park_Avenue|this page is included within other pages]])// ([[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=9288855&action=history|hist]]) -- [[https://en.wikipedia.org/w/index.php?title=Lexington_Avenue&curid=1336073&oldid=995594739|22:23]] ([[https://en.wikipedia.org/w/index.php?title=Lexington_Avenue&curid=1336073&diff=0&oldid=995594739|cur]] | [[https://en.wikipedia.org/w/index.php?title=Lexington_Avenue&curid=1336073&diff=995594739&oldid=995594662|prev]]) . . [[https://en.wikipedia.org/wiki/User:Ser_Amantio_di_Nicolao|Ser Amantio di Nicolao]] ([[https://en.wikipedia.org/wiki/User_talk:Ser_Amantio_di_Nicolao|talk]] | [[https://en.wikipedia.org/wiki/Special:Contributions/Ser_Amantio_di_Nicolao|contribs]]) //([[https://en.wikipedia.org/wiki/Lexington_Avenue|Lexington Avenue]] added to category, [[https://en.wikipedia.org/wiki/Special:WhatLinksHere/Lexington_Avenue|this page is included within other pages]])// ([[https://en.wikipedia.org/w/index.php?title=3_Park_Avenue&curid=1336073&action=history|hist]]) with - "cur" and "prev" diffs - "hist" link - correct `title` - correct `curid` See also the corollary {T148533}.
    • Task
    I had over 8000 items on my enwiki watchlist, and have thousands more on other projects like Wikidata or Commons, and when going through and removing the items via https://en.wikipedia.org/wiki/Special:EditWatchlist, the save changes button is at the entire bottom of the page, which forces me to scroll the entire page to get to it, even if I am only working in a limited section of the list. Its a terrible UX experience. I recommend floating that in the top right corner like we do on the save button in VE -- that would make it much easier to remove a group of items and save, without spending 10-20 seconds managing a long scroll (probably even worse on Commons and Wikidata).
    • Task
    Right now, the only option in [[https://en.wikipedia.org/wiki/Special:EditWatchlist|Special:EditWatchlist]] is removing a page completely from a user watchlist. Furthermore, I found de-watching and then re-watching a page (i.e. clicking a full blue star, re-clicking a star and then converting it to a half-star) just to set (or extend) expiry time more annoying. Have adding time expiry settings to "Special:EditWatchlist" been considered yet? That would make "Special:EditWatchlist" easier to use. By the way, this applies to desktop view and advanced mobile view. I wouldn't extend this request to normal mobile view yet.
    • Task
    In recent changes and watchlists the reverted edits are flagged with tags `mw-reverted`, `mw-manual-revert`. However, this is only true for local changes and information of Wikidata-edits tags arent propagated to client wikis. In context of tracking wikidata edits in other wiki than wikidata it would be important to see if the edit is already reverted so there would not be duplicating work to check manually if the vandalism still exist in Wikidata or if it is reverted.
    • Task
    The function `User::getTokenFromOption` is deprecated and has a comment that OAuth should be used. But the function is called from `SpecialWatchlist` and from `SpecialResetTokens` for the `watchlisttoken` How to replace the core feature when not using OAuth for it? Maybe there needs to be a new token store (with database table) to also handle {T65354} https://codesearch.wmcloud.org/search/?q=getTokenFromOption&i=nope&files=&repos=
    • Task
    The class SpecialEditWatchlist is extended in extension, but the class is not part of the stable policy and that does not allow to extend it. I am not sure what the best way is for the extension https://codesearch.wmcloud.org/search/?q=extends%5Cs%2BSpecialEditWatchlist%5Cb&i=nope&files=&repos=
    • Task
    Steps to Reproduce: # Turn on "Live updates" in the Watchlist. # View some unviewed pages in adjacent tabs. # Wait for some time but not until a new change appears. Actual Results: Nothing changes. As a result, after some time, one can forget if they have viewed the pages or not. and view them again. Expected Results: The viewed pages are un-bolded. Also, if the displaying of my changes is turned off in the Watchlist settings, it is expected that pages that I've viewed and edited disappear.
    • Task
    Even if one clicks ``` Hide bot edits from the watchlist ``` on https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-watchlist That does not affect ``` Email me when a page or a file on my watchlist is changed ``` on https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-personal Yes, maybe it is intended that way. Well all the user can do to stop email barrages is to clear the entire watchlist then.
    • Task
    I edited the page [[https://nl.wikipedia.org/wiki/Penitenza]] and removed a non-existing image from the code. Later I discovered part of the text was copyright violation and per local rules I removed the copyright violation from the article and rev-deleted the versions containing that text, which included the revision in which I removed the image reference. Returning to my watchlist I noticed the strikethrough formatting of the category name. {F32192515} I checked the HTML code and noticed the span with the class history-deleted ``` lang=html <td class="mw-changeslist-line-inner"> <span class="mw-title"><span class="history-deleted"><a href="/wiki/Categorie:Wikipedia:Pagina%27s_met_onjuiste_bestandsverwijzingen" class="mw-changeslist-title" title="">Categorie:Wikipedia:Pagina's met onjuiste bestandsverwijzingen</a></span></span>‎‎ <span class="mw-changeslist-links"><span>9 bewerkingen</span></span> <span class="mw-changeslist-separator"></span> <span class="changedby">[<a href="/wiki/Speciaal:Bijdragen/80.60.112.232" class="mw-userlink mw-anonuserlink" title="Speciaal:Bijdragen/80.60.112.232"><bdi>80.60.112.232</bdi></a>‎; <a href="/wiki/Gebruiker:Geschiedschrijver" class="mw-userlink userlink" title="Gebruiker:Geschiedschrijver"><bdi>Geschiedschrijver</bdi></a>‎ (2×); <a href="/wiki/Gebruiker:Mbch331" class="mw-userlink userlink" title="Gebruiker:Mbch331"><bdi>Mbch331</bdi></a>‎ (3×); <a href="/wiki/Gebruiker:CommonsDelinker" class="mw-userlink userlink" title="Gebruiker:CommonsDelinker"><bdi>CommonsDelinker</bdi></a>‎ (3×)]</span></td> ``` This only happens to the category, not the actual page. I would have expected it the other way around, because the history of the category hasn't been altered
    • Task
    See {T252812} for context. This task documents ideas for ways to purge the watchlist. The end result may for instance be a maintenance script that DBAs can run occasionally. === Problem According to the DBAs, the `watchlist` table has grown to be one of the most problematic tables. The extreme size can cause the query optimizer to malfunction. Unlike tables like `revision` and `logging`, the `watchlist` table doesn't need to be static. It serves only to convenience the end user in monitoring pages. If the end user isn't using their watchlist, the corresponding rows in the table are needlessly occupying space and in the long run affect the health and performance of the table for all other users. In addition, we have for years provided ways to automatically watch pages via preferences -- which are even on by default -- inviting scalability issues. #expiring-watchlist-items for the first time provides means to automatically unwatch, which is likely to help, but not eliminate the long-term issue. === Idea (not a concrete proposal) **Create a maintenance script to purge the many millions of unused rows in the watchlist.** Here are some ideas for the criteria; some or all may not be safe assumptions and will surely need community input: * **Bots**: On WMF wikis, the "watch pages and files I create" preference is turned on by default. Consequently, bots have created millions of rows in the `watchlist` table when seemingly they are not actually be making use of the watchlist. Some examples: ** `commonswiki`: 14% (~22 million rows) of the `watchlist` table are owed to bots, which appear to be bots that upload files and simply have the default preference set to watch them ** `wikidatawiki`: 1.1% (~91 million rows) -- for instance bots that automatically create items after articles on Wikipedia are created ** `enwiki`: 4.7% (~10.3 million rows) -- take [[ https://en.wikipedia.org/wiki/User:ClueBot_NG | counter-vandalism bots ]] for instance; they create User talk pages when issuing warnings ** `mgwiktionary`: 99.8% (~13.2 million rows) -- a single bot mass-created nearly every entry on the wiki * **Foundation-banned users**: They are explicitly not welcomed to return to our projects, so presumably their watchlist could safely be cleared * **Community-banned/blocked users**: After some grace period (say, 5 years) it may be acceptable to clear their watchlists * **Retired users**: Some accounts have left the project ages ago with no intention to return, but their rows in the `watchlist` table remain. This (sadly) may include [[ https://en.wikipedia.org/wiki/Category:Deceased_Wikipedians | deceased users ]], many of which were quite prolific. * **Deleted pages**: Users typically don't think to unwatch pages after they've been deleted. There are legitimate reasons to continue watching these titles (say to be notified when they're recreated), but the ratio of when they are recreated versus never return might be worth investigating. Perhaps some sort of grace period is reasonable -- say if the page was deleted 5 years ago, the purging routine could automatically unwatch them. * **Humans using (semi-)automation**: Similar issue to with bots. Some non-bot accounts use automation to mass-create pages, unknowingly watching each and every one of them. It will be difficult to identify such accounts, but for instance if a human is watching millions of pages, it's probably safe to assume they aren't getting much out of Special:Watchlist due to how slow it is, if it even loads at all.
    • Task
    Hi. Could we please see the number of currently shown edits on Special:Watchlist? For example, if one has 1000 edits maximum and they see 900, that means that they need to open them quick, before it becomes 1000. And if it's 1000, there is a chance that there are more, and only these are the shown. I think it is very easy. For example, just count the div elements of some kind on the page. Thank you.
    • Task
    In the "User Profile" tab of Preferences there is the option to "Email me also for minor edits of pages and files." However, this option does not take into consideration edits marked with `nominornewtalk`. These edits are usually associated with bots archiving talk pages, meaning that if the "newest edit" is by such a bot, the user will not get an email notification about the change, and thus will not get notified of any further edits to that page. Please add an additional checkbox or sub-option to allow emails for //any// minor edit, regardless of whether `nominornewtalk` is set.
    • Task
    Steps to Reproduce: 1. On a Special:Watchlist have all items as "seen" (or have a mix of "seen" and "unseen"). 2. Reload the page - the solid bullet points will be displayed while the page is loaded. (click to see the animated gif) {F31769690} Expected Results: This issue is minor - and what would be the expected result may vary - showing the bullet point only when there is certainty what state should be displayed (filled in (solid) or empty)? Or showing them as empty ones and then filled them in according to their status "seen/unseen"?
    • Task
    >>! In T218511#6065425, @kostajh wrote: > There is a remaining issue, that might be deserving of its own task: * you are watching an article * someone makes three edits to that article with revisions 2, 3 and 4 * revisions 2, 3 and 4 show up on your watchlist because you have the "Expand watchlist to show all changes, not just the most recent" preference enabled * revisions 2, 3 and 4 are in bold / unseen, as expected * you click on the diff for revision 2 * you reload the watchlist, //before// the `updateWatchlistNotification` job has executed * expected behavior: when reloading watchlist, revision 2 is marked as "seen" and revisions 3 and 4 remain "unseen" * actual behavior: revisions 2, 3 and 4 are marked as "seen" * addendum to actual behavior: when the `updateWatchlistNotification` job (which was created when you clicked on the diff for revision 2) runs, the watchlist is now in the correct, expected state where revision 2 is marked as "seen" and revisions 3 and 4 are marked as "unseen"
    • Task
    As a watchlist user, I want the logic for parsing expiries to be consolidated, so that the tool can run with efficiency and reliability in the back-end. **Background:** We have basically the same logic for parsing "expiry" user inputs in WatchedItemStore::updateOrDeleteExpiries(), SpecialBlock::parseExpiryInput(), SpecialUserrights::expiryToTimestamp(), ProtectionForm::getExpiry(), ApiProtect::execute(), FlaggedRevs PageStabilityForm::getExpiry(), and possibly other extensions as well. With minor variations, that code is generally[1] ```lang=php if ( wfIsInfinity( $expiry ) ) { return 'infinity'; } $unix = strtotime( $expiry ); return $unix === false ? false : wfTimestamp( TS_MW, $unix ); ``` We should probably consolidate that logic into one place, possibly with additional error checking to avoid accepting past expiries and such. Also, for the benefit of APIs[2] we might also add 'expiry' as a type to ParamValidator. [1]: Well, most of them still have checks for PHP 5.0 returning -1 instead of false on invalid input. I left that out here. [2]: In the Action API in core, we could use it in ApiBlock, ApiProtect, and ApiUserrights, and ApiWatch. **Acceptance Criteria:** * Consolidate logic for parsing expiries
    • Task
    From Special:EditWatchlist, I select about 1000 items using the Shift+Click trick, then I press Remove button. No pages are removed: the page is only reloaded and some last items I had checked are unchecked. No error message is displayed, POST request returns an HTTP 200 state code. If I press Remove button again, the same happens. I tried to uncheck about 20 items in addition to those which were automatically unchecked, then submit. In this case, an error message is displayed (something like “not all pages can be listed”) but all selected pages seem to be well removed. Maybe related: {T41510}
    • Task
    @Janbery complains about notifications sent about changes made by User:Oznamovatel at cs.wikipedia doesn't dseem to be reliable. On 2020-02-20T14:50 UTC+1, but Janbery has no email. His email address is jan.beranek@wikimedia.cz. As a Wikimedia system administrator, I've checked that no email was received by the mailserver. Could you please check Wikimedia's end?
    • Task
    Steps to Reproduce - Download the [[ https://accessibilityinsights.io/docs/en/web/overview | Accessibility insights for web extension]] - Navigate to the watchlist - Click on the Accessibility insights tool icon, you can find the icon beside the navigation bar - Click Fastpass {F31506531}
    • Task
    `mediawiki.special.watchlist/watchlist.js` should use a `timestamp` parameter in the api call to mark all pages as seen, so that changes that haven't loaded yet are not missed. ###Story As a user, When I load my watchlist, And click "Mark all changes as seen", Only changes that were made prior to loading the watchlist should be marked as seen, So that any changes made between loading and clicking "mark all changes as seen" are not missed
    • Task
    [[https://translatewiki.net/wiki/MediaWiki:Enotif_body/en |Enotif_body]] says that you can: ``` Contact the editor: mail: https://en.wikipedia.org/wiki/Special:EmailUser/Example wiki: https://en.wikipedia.org/wiki/User:Example ``` If the user wants to contact User:Example by leaving a message on wiki, then a link to User_talk:Example (not User:Example) would be more appropriate.
    • Task
    My watchlist on the Hungarian Wikipedia (//Show Wikidata edits in your watchlist// is ON) incorrectly says that [[ https://www.wikidata.org/w/index.php?title=Q74463065&action=history | this item ]] was deleted. But in reality, the item was just merged and [[ https://www.wikidata.org/wiki/Special:Log?type=delete&user=&page=Q74463065 | its deletion (and other) log is empty ]]. The issue is also re-creatable on the English Wikipedia; add [[ https://en.wikipedia.org/wiki/Ann_Walker_of_Lightcliffe | Ann Walker of Lightcliffe ]] to your watchlist, turn ON //Show Wikidata edits in your watchlist// and check your watchlist. {F31203527}
    • Task
    I have 4 pages (Blair Gormal, Marcus Hale, Phoenix Decker, and Talk:Marcus Hale) in my English Wikipedia watchlist that were all deleted at around the same time. When I visit one of the 4 pages, the corresponding bullet point on Special:Watchlist changes from unvisited to visited, but then when I visit another one of the 4 pages, the first bullet point appears to temporarily change from visited back to unvisited. Eventually, however, all 4 pages correctly show as visited bullet points. Expected result: Visiting two pages in the watchlist that were both deleted or edited at the same time should not cause the bullet point for the first page to change itself back to the unvisited color, temporarily or otherwise.
    • Task
    At a page such as https://translatewiki.net/w/i.php?title=MediaWiki:Addwatch/en&action=watch there are 2 strings that are nearly identical: * https://translatewiki.net/wiki/MediaWiki:Addwatch and https://translatewiki.net/wiki/MediaWiki:Confirm-watch-top * https://translatewiki.net/wiki/MediaWiki:Removewatch and https://translatewiki.net/wiki/MediaWiki:Confirm-unwatch-top **Problem**: Because of this redundancy, some wikis have blanked one of the strings locally. E.g. https://ru.wikipedia.org/w/index.php?title=MediaWiki:Addwatch&action=history which thus displays as https://ru.wikipedia.org/w/index.php?title=MediaWiki:Addwatch&action=watch&uselang=ru **Proposal**: Clarify the distinction between the title and the description to eliminate redundancy. E.g. ```Title: "Add to watchlist" Description: "Click <ok string> to add the page and associated talkpage into your watchlist. Learn more at <help link for watchlists>"``` or similar.
    • Task
    Translation admins on multilingual wikis tend to work in a bot-like manner, scores of rapidly successive edits. When I watch a page I am interested in actual content changes, but my watchlist is nowadays cluttered with translations updates that are of no use to me. Thus effectively hiding the actual changes I am //watching// for. {F30503953} Please provide a way to filter them completely from watchlist and recent-changes the same way bot edits are filtered.
    • Task
    Current behaviour (actual results) Structured discussion topics that are watched show on the mobile watchlist with a opaque names like "Topic:V7rw8rgxreagqbps". Desired behaviour (expected results) Watchlist contains name of topic and preferably also the name of its board. Watched boards display as expected, issue occurs only with topics. {F30466084} {F30466085} Steps to reproduce 1. Find a wiki that has SD enabled, e.g. MediaWiki wiki. Log in. 2. Locate a suitable discussion board. 3. Tap the star to watch a topic, or add a comment to autowatch it. 4. Have someone post a reply to the topic. 5. Compare the watchlist appearance on desktop versus mobile.
    • Task
    I am not entirely sure why this change was made, but I do not display filters at any given time. With the most recent deployment, now I cannot access the button which says "View new changes since date-time" without displaying all of the filter options. That's a significant reduction in density of information above the fold, which is an unnecessary hassle for me (after I've gotten through all the changes since I went to bed--I do the 'hit f5 every minute' kind of thing). Please tweak this change. Used to appear around the arrow head {F30004450} (Aside, I do not understand what that whitespace is doing there.) Now it appears {F30004452} I'm also not sure about the other stuff that got moved over, but since those are settings-like and probably won't change too often, those seem reasonable there.
    • Task
    Too much indentation, and it seems to be more at enwiki than nowiki, which is really weird! Perhaps nowiki didn't get an update? At nowiki we are missing this bug and feel neglected! Is it some work-in-progress that got rolled out in a half-done state? Also note [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problem_with_watchlist_display | w:en:Wikipedia:Village pump (technical)#Problem with watchlist display ]]. {F29513332} Bug at enwiki {F29513401} Less buggy nowiki
    • Task
    I have the edits since I last looked at the article grouped together. If these edits make no change to the article in question I would like the ability to filter them such that they do not appear in my watchlist. For example this comes up on my watchlist `19:48 Benzodiazepine‎‎ 2 changes history0‎ [TheDoDahMan‎; 2601:345:8302:1521:74DC:31C5:126:D939‎]` Which gives no change https://en.wikipedia.org/w/index.php?title=Benzodiazepine&curid=4781&diff=899549485&oldid=899229888&diffmode=source
    • Task
    As Wikipedians, we need the ability to see ONLY changes to WikiData elements used within Wikipedia articles within our Wikipedia watchlists. Amir has made great progress towards this goal here {T90436} with only a few steps left to complete it. One is: 1) Not include changes to descriptions used in other languages m D 22:13 Aspirin‎ (Q18216) (diff | hist) . . Dingens5 (talk | contribs) (‎Added [de] alias: ASS; ‎Added [de] alias: Aspirin®)
    • Task
    As Wikipedians, we need the ability to see ONLY changes to WikiData elements used within Wikipedia articles within our Wikipedia watchlists. Amir has made great progress towards this goal here {T90436} with only a few steps left to complete it. One is 1) Make it optionally whether new language versions of articles appear in the watchlist m D 09:58 Color blindness‎ (Q133696) (diff | hist) . . Lorem Ipsum (talk | contribs) (Language link changed from it:Daltonismo toit:Discromatopsia)
    • Task
    In en.Wikipedia, I log in and go to my watchlist, which defaults to 1,000 items and 30 days, but it retrieves only a few days, sometimes with about 50 items. It turns out that the solution is to exclude Category. I don't even have to exclude Category Talk. Instead of excluding, I can explicitly include everything except Category. Thus filtered, I get late April to May 18. With Category, I get May 14-18 only. The time stamp of the earliest item on May 14 varies. I don't know how to get 30 days of Category namespace items. While Category alone truncates the date range, Category with one or more other namespaces truncates too, but a little differently. See also, all in Wikipedia's Village Pump (Technical), in reverse chronological order: * [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#watchlist_too_short_again | Watchlist Too Short Again]] * [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_174#did_something_break_watchlist_and_make_it_too_short_again? | Did Something Break Watchlist and Make it Too Short Again?]] * [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_169#watchlist_or_Recent_Changes_showing_too_few_changes,_kludge_to_URL | Watchlist or Recent Changes Showing Too Few Changes, Kludge to URL]] (Apparently, there's no Phabricator tag for anything like en-WP.)
    • Task
    Topic: edits are currently included in the "Other" tab of the Watchlist in Mobile interface (together with project, help, template namespaces) They should better appear in "Talk" tab (together with other talk namespaces) === User Story The watchlist talk tab is a nice place to visit watched conversations. Unfortunately, it only lists pages in the main talk namespace and not in other talk namespaces such as user talk or help talk. The logic should be updated to check if a page is in [[ https://github.com/wikimedia/marvin/blob/master/src/common/models/page/namespace.ts#L44 | any talk namespace ]]. === Acceptance Criteria [] The talk tab shows pages from all talk namespaces [] The other tab doesn't show pages from any talk namespace. For example, in the current implementation, help talk pages are shown: {F28643161} = Developer notes SpecialMobileWatchlist::getNSConditions is where the magic happens Defined like so: ``` case 'articles': // @fixme content namespaces // Has to be unquoted or MySQL will filesort for wl_namespace $conds[] = "$column = 0"; break; case 'talk': // check project talk, user talk and talk pages $conds[] = "$column IN (1, 3, 5)"; break; case 'other': // @fixme $conds[] = "$column NOT IN (0, 1, 3, 5)"; break; } ``` We'll either need to change those numbers in other or talk to match all talk page namespaces or say column is odd number and column is not 0 for talk (the opposite for other). The `MWNamespace::getTalkNamespaces()` function is probably what we are looking for here. 'articles' can remain hard coded.
    • Task
    Per T222533, The speed of clearing Special:Watchlist via /raw and /clear should be improved so a change is applied immediately similar to /edit rather than going through the job queue which can take significantly longer
    • Task
    Per discussion below, a message should be added to Special:Watchlist to alert users that /raw and /clear use the Job queue and it may take a while. --Original Report-- When clearing my watchlist it took a while to update and show no pages were on there Method 1: 1. Visit Special: Watchlist 2. Click the edit button 3. Then clear this watchlist 4. Press the big red confirm button 5. See an error stating too many pages to display {F28931371} 6. Return to your watchlist - It will not be cleared 7. Wait about an hour and return to your watchlist. It should be clear Method 2: 1/2: As above 3. Click edit raw watchlist 4. Select everything in the box and blank it 5. Save changes 6. As above (5/6/7) NB: This is displayed on enwp with 1428 pages (excluding talk) on the Watchlist being cleared
    • Task
    Example confusing flow for a user of the newer watchlist interface. 1. Go to Special:Watchlist. See a bunch of minor edits (because they're included by the user's current default filter) 2. Go to Special:Preferences -> Watchlist 3. Check "Hide minor edits from the watchlist", and save. 4. Go to Special:Watchlist again. Minor edits are still showing up! Based on some experimentation, it seems like all of the flags under "Changes shown" and the "Expand watchlist to show all changes..." flag under "Advanced options" only do anything if you're also electing to use the non-JavaScript interface (also under "Advanced options"). Even assuming this isn't a bug (which is not totally obvious), I think it's confusing. Maybe some text could be added to indicate that these only apply to the non-JS interface? Or maybe these options, along with the "Use non-js interface" flag itself could all be grouped under a "Non-JavaScript interface" heading?
    • Task
    If while editing an article, you change its "watchlisted" status, the star will be inconsistent after the article reloads. The problem happens when you check the "watch this page" check mark at the bottom for an article you weren't watching previously, or when you uncheck it while editing an article that was in your watchlist up to that point. After pressing "Publish changes", when the article reloads, the star will show the status previous to the edit, not taking into account the aforementioned change. If the page is reloaded manually, the indicator will be corrected.
    • Task
    Steps to Reproduce: * Activate `watchlistunwatchlinks`. * Load a watchlist. * The items on the watchlist have a ×. * A click on × is handled via JavaScript. * Change the rcfilter to load additional items. * The new items have also a ×. Actual Results: * A click on × is not handled via JavaScript. The fallback URL is loaded. Expected Results: * A click on × is handled via JavaScript.
    • Task
    ====Problem Go to https://commons.m.wikimedia.org/wiki/Special:EditWatchlist ("List" tab of Watchlist via mobile view) and then see that uploaded files (see also https://commons.wikimedia.org/wiki/Help:Namespaces) are not listed there. Instead, if you add any page belonging to "0" (or main) namespace, like https://commons.wikimedia.org/wiki/Bradley_Cooper, into your personal watchlist, then you would see that page listed there (until you un-watchlist it). The "0"/"main" namespace comes from Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Namespace Also, go to https://commons.m.wikimedia.org/wiki/Special:Watchlist and then click "Pages" tab; you'll see that only pages belonging to the "0" namespace would be listed there. To see uploads and "Commons:" pages, go to either "Other" or "All" tab. However, the pages are harder to search on the mobile watchlist, especially if a watchlist contains hundreds or thousands of uploaded files (and some other pages). I previously [[https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical/Archive/2019/03#%22List%22_tab_of_Watchlist_on_mobile_view|addressed this at Commons's VP]] but hadn't received a reply. Here I am readdressing this. ====Expected results I should see uploads and/or "Commons:" pages listed as "Pages" or, separately, "Files"
    • Task
    Every time I go to my watchlist 50%+ are edits that were reverted by some anti-vandalism bot or user. I can easily tell those edits from the rest by the 0 bytes added mark, and also because I already recognize the names of usual anti-vandalism bots. However, I think it would be a step forward to have a filter to hide all edits that have been reverted, so that the watchlist only displays changes that are worth seeing!
    • Task
    on march 15th (around 18:00 (CET) ) a brief bug was noticed concerning special:watchlist on fr:wikipedia. Steps to Reproduce: open a diff of your watchlist, reload the watchlist. Actual Results: the article title stay in bold. Expected Results: the article title should not be bold anymore. the bug was "resolved" 25-30 minutes after I first spotted it. Today (march 17th) around 13:30 (CET) I noticed the bug was strinking again. This time, it lasted around 20 mn. **Hewiki comment**: We already saw it every couple of hours. The API query for unread edits returns all rhe bold ones all the waiting time.
    • Task
    If the watchlist methods `\WatchAction::doWatchOrUnwatch`, `\WatchAction::doWatch` or `\WatchAction::doUnwatch` are called with an invalid `Title` object, then the database is corrupted and editing the Watchlist via `Special:EditWatchlist` is longer possible (see screenshot). {F28289799} --> These methods must validate the `$title` parameter!
    • Task
    @writ_keeper has a very neat script that adds an [inline diff] button to Watchlist entries, and then when clicked, embeds the diff of the change inline, and marks it as read: https://en.wikipedia.org/wiki/User:Writ_Keeper/Scripts/inlineDiffDocs {F27350438} {F27350441} I think this would fit well in the recent watchlist enhancements, maybe by adding a checkbox to the new watchlist settings panel that says "Open diffs inline", and if enabled, when you click on the diff link, it opens it inline.
    • Task
    (1) The warnings for invalid user input on RC/Watchlist 'Display options' fields in FF look quite different from the same warnings in Chrome. FF63 {F27323365} Chrome70 {F27323367} (2) Another FF-specific issue - the warning gets de-attached and scrolls to the top of the screen:
    • Task
    ==== Problem Statement In most cases, users watchlist entries (on **Special:EditWatchlist**) can grow as large as >700 articles and figuring out the latest article added to watchlist (for example) is a difficult task (taking into consideration the user can't even remember the name of this particular article that was added), so, I was experimenting on building an extension (say WatchListFilter extension maybe?) to filter watchlist based on various parameters (like `desc order of timestamp`, `asc order of timestamp`, `date added`, etc) but by default, based on their timestamps added. See also: {T100508}, {T208487} ==== Proposed Solution MediaWiki already has a way of dealing with Timestamps, see https://www.mediawiki.org/wiki/Manual:Timestamp, which is very nice so a solution to handle this problem would be altering the watchlist table to add the `wl_addedtimestamp` attribute to it so it can be used in the filtering process. The attribute will store MW timestamp that will be used by MW or other extensions that may need this feature. There would be a lot of filters that can help the users find the article added to watchlist without knowing the name of the article; * ASC order of TS * DESC order of TS * Range TS / Date search * Order by Alphabet (this can make use of other attributes in the watchlist table) * Filter by Regex * etc | **Motivation** | **Other thoughts** | | Trying to solve the finding watchlist entry problem with an extension I'm intending to work on "WatchListFilter". | Whether the feature may be made available in core could be a different topic for discussion but the basic level usage here is for an extension. Also, other topics as per how the filter will look on the Special:EditWatchlist special page based on the OOUI-fication that has happened and others can be addressed on other tickets, maybe sub-tasks of this one I guess :) ==== Alternative solutions I've not had deep investigations on an alternative way to solve this problem with other means different from this proposal. Looking at the current watchlist table, I don't yet see an alternative means although there may be a way I don't yet know but others do :). As proposed here: T209773#4756088, that can be another approach in introducing this feature. ==== Side effects * More data going into the database which will increase the DB size over time, this feature is quite advantageous as other things can be built on it like the WatchListFilter extension etc. * After adding this attribute to the table (approach 1) or even approach 2 (as suggested by Brian), items already added to watchlist before the introduction to this feature will have no timestamp or default timestamp (which can cause some inaccuracy in the filtration process). So this is something worth noting how to deal with. * Another side effect (adv) can be that, this feature can act as a partial "watch this and read for later" as the user won't bother to bookmark the page or remember the name of the article. All the user needs to know is the approximate time the article was added to their watchlist and the filter can be used to figure the potential article. --- ==== Use cases (3 most possible scenarios) (1) **Getting the latest entry added watchlist**: Assuming I added an entry to watchlist few days ago but have forgotten the exact name of the article but I've not added any other entry to my watchlist (so the one I added few days ago is the latest added), the current system can't tell which was the last entry added but with a feature like this, the user can just sort by/filter by descending order of time added and the first entry at the top of the list will be the one that was lastly added and then read it. So the user won't bother thinking or trying to figure out the name, the filter will help the user achieve that. (2) **Finding an entry in watchlist in order of alphabet**: In another scenario, this kind of filter could be needed when the watchlist entry is added (at any time) but the user only knows the first letter that the article begins with. So the user can just filter the entries in ascending or descending order of alphabet or use a regex to get just all the articles in the tries that begin with "A" (for example) and then check the resulting list and see if the article will be found. (3) **Get the oldest watchlist entry**: In some cases, users would want to cleanup their watchlist entries but may want to begin with the oldest added to watchlist but currently they can't know exactly which one is the oldest as there is way for MW to figure out that. So with a feature like this, there can be a filter to filter in ascending order of time added and then the latest at the top of the entry would be the oldest. If the user hasn't read it yet, he/she may read it and then remove it from watchlist and the process continue so very old watchlist entries are removed (some clean-up to watchlist approach). I would not want to cleanup/remove what I just added yesterday so a filter will help me do this. --- ===== Comments An RfC was filed some weeks ago (as of today) which was quite wrong per the request, see https://phabricator.wikimedia.org/T208487, thanks to @daniel, @aaron, @Catrope, @Anomie for feedback that enlightened me to create this "real" RfC proposal. This RfC is a product of T208487.
    • Task
    @Kaartic points out in T196893#4727233 that [[ https://en.wikipedia.org/w/index.php?title=D%C3%A9j%C3%A0_Vu_(Beyonc%C3%A9_song)&action=watch&useskin=vector | when visiting the non-JS fallback for watching a page ]] there is no way to cancel/return to the page. On Minerva after watching a page you see: {F27087072} On Vector the experience has similar problems (but at least you can click the "read" tab at the top. {F27096362} I'm guessing it would make sense for the page title to be a link and to add a "no" option in this form: {F27096368}
    • Task
    Hi. # Open Special:Watchlist. # Close the browser. # Wait a while. # Reopen the browser on the same tab. Expected: an updated version of the watchlist. Got: the same version as in paragraph 1, from the browser cache. Started on last deployment. Recognized on Lollipop Chrome 68. Thank you.
    • Task
    === Error === Request ID: `W5@o9grAAEAAADq-rAwAAAAK ` ```name=message Query: UPDATE `watchlist` SET wl_notificationtimestamp = '##############' WHERE wl_user IN ('###, '###', ..., '###') AND wl_namespace = '0' AND wl_title = '***' Function: WatchedItemStore::updateNotificationTimestamp Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.192.48.114) ``` ```name=stacktrace,lines=10 #2 /srv/mediawiki/php-1.32.0-wmf.20/includes/libs/rdbms/database/Database.php(2074): Wikimedia\Rdbms\Database->query(string, string) #3 /srv/mediawiki/php-1.32.0-wmf.20/includes/libs/rdbms/database/DBConnRef.php(49): Wikimedia\Rdbms\Database->update(string, array, array, string) #4 /srv/mediawiki/php-1.32.0-wmf.20/includes/libs/rdbms/database/DBConnRef.php(309): Wikimedia\Rdbms\DBConnRef->__call(string, array) #5 /srv/mediawiki/php-1.32.0-wmf.20/includes/watcheditem/WatchedItemStore.php(833): Wikimedia\Rdbms\DBConnRef->update(string, array, array, string) #6 /srv/mediawiki/php-1.32.0-wmf.20/includes/deferred/MWCallableUpdate.php(34): Closure$WatchedItemStore::updateNotificationTimestamp() #7 /srv/mediawiki/php-1.32.0-wmf.20/includes/deferred/DeferredUpdates.php(268): MWCallableUpdate->doUpdate() #8 /srv/mediawiki/php-1.32.0-wmf.20/includes/deferred/DeferredUpdates.php(226): DeferredUpdates::runUpdate(MWCallableUpdate, Wikimedia\Rdbms\LBFactoryMulti, string, integer) #9 /srv/mediawiki/php-1.32.0-wmf.20/includes/deferred/DeferredUpdates.php(134): DeferredUpdates::execute(array, string, integer) #10 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(914): DeferredUpdates::doUpdates(string) #11 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(734): MediaWiki->restInPeace(string, boolean) ``` == Notes === Happens on may different wikis, although majority from commons.wikimedia.org and vi.wikipedia.org. It happens on page views, EditPage edits, and API edits. The query looks similar to T204555, but comes from different code triggered by different circumstances. It might be that both can be fixed in the same way, but they will probably each require a separate fix. See also: * {T134613} * {T188801}
    • Task
    I recently tried to edit my ~6,000 entries Watchlist on en-wiki using the raw watchlist editor feature. Unfortunately, I did not notice that only half of the entries were loaded and when I clicked save, ~3,000 entries were gone. I checked Phabricator but couldn't find a bug report about it. Since my watchlist is now smaller, I cannot reproduce it either.
    • Task
    With Echo we have the option of setting how we want to be notified about most events. Importantly we can choose if we want the notification delivered via web, email or both through mw-prefsection-echo. The exception to this are watchlist notifications where we can choose to have these notifications delivered as email on mw-prefsection-personal but we cannot chose to have them delivered as a web notification. For new contributors this leads to some confusion as there is no reason to see the watchlist email notifications as any different from other notifications. Infrastructure wise it means we have to maintain two separate notification pipelines.
    • Task
    [[https://www.mediawiki.org/w/index.php?title=Topic:Uj7w62a5lforw4i2|Based on this feedback on mediawiki.org]] The goal is to have a way to open all pages displaying changes that have happen after the last visit.
    • Task
    The bottom part feels a bit short on margin. Made me think that the modal panel was actually clipped and I could scroll for more, but alas, there is not more, just a bit of missing padding/margin. {F24434289}
    • Task
    It is slightly confusing that when you change your preferences and refresh your watchlist, that these changed preferences do not take effect. This is because your previous settings are reflected in the URL, and these take preference over the defaults. It might be a good idea to track the integrity of the previously used defaults, and inform the user when a 'conflict' is detected. "Your preferences have changed since you last visited. Would you like to reload this page with your new preferences?" Would required some sort of edittimestamp being passed in the url params or something and conflict detection. Might be a good idea to apply this somewhat wider into the core of the preferences, as with the increase in dynamic content, this might start popping up in other areas with dynamic/single page logic too.
    • Task
    Steps to reproduce: # make your preferences not exclude anything from your watchlist (ie. don't hide minor edits, bots, Wikidata edits etc. by default) # go to Special:Watchlist # ('Active filters' area should be empty) # notice there is 'Restore default filters' in the right bottom corner of 'Active filters' area If you click that button, nothing happens.
    • Task
    I'm using the extended watchlist (that shows all edits and not just the last one) and for one talk page there is a revision missing. This is what my watchlist shows for that page today: {F22681547} This is what the history of the page says: {F22681597} Affected page: https://nl.wikipedia.org/wiki/Overleg:Klavarskribo Missing revision: https://nl.wikipedia.org/w/index.php?title=Overleg:Klavarskribo&oldid=51861003 The affected revision is also missing from the recent changes
    • Task
    It seems a little strange to use spaces to align the lists in 2018. {F18162664} {F18162567}
    • Task
    I just want to see my open cases on [[Project:Support_desk]]. The "Watchlist" link in toolbar links to Special:Watchlist, which is sorted by date, like an activity log. Cases are repeated for each update, like an activity log rather than subscription list. At the least, the toolbar link should be more correctly called "Activity Log", not "Watchlist". It would be even more helpful if toolbar linked to Special:EditWatchlist instead, because that lists each case only once. Would be even more helpful if Special:EditWatchlist showed Open/Closed status. thx
    • Task
    Watchlist entries do not have history of how they were added or why. Some people put effort into identifying a reason for each of their watchlist entry, and in some cases do not see why it was added. I'd suggest to log watchlist changes: when and why a page was added to watchlist. For example April 3, 2011 Foo was added to your watchlist because you created the page April 12, 2011 Bar was added to your watchlist because you edited the page April 14, 2011 Baz was added to your watchlist because you added it to watchlist yourself
    • Task
    {F13874938} Sometimes my English Wikipedia watchlist (I'm using the new version) gets flooded by experienced Wikidata editors and/or bots using QuickStatements. I can't turn this off by excluding edits by "experienced" (500/30) users. It would be nice to be able to hide them, or alternately, to be able to hide all edits by specific users.
    • Task
    When testing the recently merged clearing of users watchlists using the job queue I was expected to view the 'watchlistedit-clear-jobqueue' i18n message after clicking the submit button. Instead I get a generic "There are too many pages to display here." message with no indication of success or what is happening. This also happened before jobqueue watchlist clearing was implemented. - clearUserWatchedItems is called in SpecialEditWatchlist which clears the watchlist either using the jobqueue or synchronously. - The successMessage is passed into SpecialEditWatchlist::showTitles which tried to show all title removed, however, if more than 100 titles are in the list 'watchlistedit-too-many' is instead shown with no list and the previous successMessage is discarded. I would expect in both cases that the success message would still be shown alongside either a list or the 'watchlistedit-too-many' message.
    • Task
    @Misibacsi [[ https://hu.wikipedia.org/wiki/Wikip%C3%A9dia:Kocsmafal_(m%C5%B1szaki)#Cikkm%C3%A9ret_a_Figyel%C5%91list%C3%A1n | would like to see ]] the size of the pages on Special:EditWatchlist. It would be useful to find the short ones. Special:ShortPages lists the shortest ones, but most of the time the results aren't relevant (hard to find one which would interest the user). Is it possible?
    • Task
    Hello. I strongly recommend High priority, despite it is not page content lost, but still, the user loses a lot of information. # User A has page X in their watchlist. # There are a couple (one is enough, but let's say 5) unseen revisions of X. # Before revision 1 there was their own revision of X. # User C thanks to user A for that revision. # User A gets notification about this thank. # User A clicks on notification and opens the thanked revision. # Unexpected result: Revisions 1-5 marked as seen. Recognized many times, including five minutes ago. But at least once it worked as expected. Thank you.
    • Task
    This ticket comes from the RFC mentioned in T184000 This is how I interpret the issue: For users with very large watchlists, lag in changes being dispatched to clients can apparently cause 'new' changes for watched items to appear fairly far down the watchlist view. For example: - User is watching article A - Item Q1 is edited on wikidata (linked to an article watched by the user on the wikipedia) - 15 other articles are editing on the wikipedia the user uses and their changes appear in their watchlist - Dispatching of the change finally occurs 5 minutes later - The edit for Q1 / the linked page appears on line 16 in the watchlist? and can easily be missed? This should probably be tested and confirmed. A solution would be to order the entries in the watchlist by time added rather than time that the change actually occurred on wikidata.
    • Task
    === What happened? **TL;DR **: I had to reset my //Watchlist token// to subscribe to the Atom feed of my Watchlist for the first time. I just recently discovered from [[https://en.wikipedia.org/wiki/Wikipedia:Syndication#Watchlist_feed_with_token|Wikipedia:Syndication#Watchlist_feed_with_token]] that I could subscribe an Atom feed of my watchlist even when I'm logged out, cool! Anyways, it wasn't a "Follow the steps to get the desired results" thing. The step 3 seems to have become outdated. Anyways, I managed to discover the link to subscribing to the Atom feed in the left bar on my Watchlist page. I thought I could subscribe to the Watchlist at last. Unfortunately, I wasn't successful yet. I got the following error, ``` Error (bad_wltoken) Incorrect watchlist token provided. Please set a correct token in [[Special:Preferences]]. ``` Then I digged a little bit and found a link to //reset the Watchlist token// on my Preferences page. Only then was I able to successfully subscribe to the atom feed! == What's the issue? **TL;DR**: Requiring the user to reset the //Watchlist token// before he could subscribe to the Atom feed of his Watchlist for the first time. Now, coming to the issue, it doesn't seem to be a UX that every user should reset their //Watchlist token// to subscribe to the feed. Of course, I also suspect this is not intentional. ==== What do you expect? I expect to subscribe to the Atom feed of my Watchlist for the first time on different wikis without having to reset the //Watchlist token// on each of them manually. BTW, sorry in case the tag is the wrong one! I couldn't find a better one!
    • Task
    From [[https://www.mediawiki.org/wiki/Topic:U3bpqd8mzypo5hb7|that idea]]. **Problem** At the moment, it is not possible filter pages on a watchlist by a personal key: article I'm working on now, community pages about sport, pictures that I have changed the description... **Possible solution** Have a way to tag pages added to the watchlist with some personal tags. Those tags are unique to the user and would complete other filtering options very well. Users can then filter by personal tags (and categories, namespaces type of edits... by potentially excluding them (T174349)) and [[ https://www.mediawiki.org/wiki/Help:New_filters_for_edit_review/Bookmarking | save those filtered queries ]]. This would also solve the need of {T3492}, a community whishlist item in 2015, 2016 and 2017.
    • Task
    I was trying to watch a talk page without watching the corresponding subject page (which, I have been informed, is not currently supported). If I add just the talk page `Talk:Q42` on [[Special:EditWatchlist/raw]], the message is: >Your watchlist has been updated. 1 title was added: > >* Talk:Q42 (talk) But in fact `Q42`, both subject and talk, have been added, and opening [[Special:EditWatchlist/raw]] again shows that the actual added entry is just `Q42`. If I then change that to `Talk:Q42` (i. e., the content is the same as with my previous edit), the message is: >Your watchlist has been updated. 1 title was added: > >* Talk:Q42 (talk) > >1 title was removed: > >* Q42 (talk) But in fact, the watchlist again contains `Q42`. The behavior seems to be more or less intended (if you don’t want to support watching talk pages independently of subject pages), but the messages misleadingly suggest that this might actually be supported.
    • Task
    While loading Recent Changes/Watchlist with combined items, the line height shifts, making content after the first or second collapsed item to slightly shift up, while the rest of the page is stable during load. See the screenshots (from https://de.wikipedia.beta.wmflabs.org/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=30&enhanced=1&urlversion=2): {F11103322} {F11103324} Starting with the entry from 10:50 the contents slightly move up during load. This happens with disabled RC filters, too. It's also visible on the watchlist.
    • Task
    [[ https://www.mediawiki.org/w/index.php?title=Topic:U2rt9ptfmwc31vwd | Initial report. ]] **Issue** As a user, I can't easily determine the beginning and end of a recent change item. It often has to struggle to see where the entry ends when there are a lot of very verbose changes. **Proposed solution** Add css to highlight the specific line on mouse hover, e.g.: ``` .mw-changeslist-line:hover { background: lightgray; } ```
    • Task
    Hello. Opt in grouping by page in preferences. * In recent changes, grouped edits font is smaller than single. * In watchlist, grouped edits font is larger than single. Checked with safemode. Recognized on Android.
    • Task
    As a user, when I'm visiting my `Special:Watchlist` page it would be good to know about the existence of `Special:Preferences#mw-prefsection-watchlist` as these settings effect the behaviour of `Special:Watchlist`. There are already several links to editing your watchlist from `Special:Watchlist` but there is no mention of the watchlist configuration in `Special:Preferences` which effect the behaviour of `Special:Watchlist`. For example, settings under `Advanced Options` control what defaults are set on `Special:Watchlist` and settings under `Display options` can stop any results from loading on `Special:Watchlist` at all (although this doesn't appear to be intended behaviour - see T176033). This deeplink could be added to `mw-watchlist-toollinks` at the top of the page so instead of displaying: > For username (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist) It might instead display: > For username (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist | Edit watchlist preferences) For the discussion on what caused this enhancement request see: T176033.
    • Task
    Injecting recent changes from Wikidata is currently disabled on Commons: ```lang=php,name=wmf-config/InitialiseSettings.php 'wmgWikibaseClientInjectRecentChanges' => [ 'default' => true, 'commonswiki' => false, // T171027 'testcommonswiki' => false, // T171027 ], ``` With T177707 and T173194 being solved it should be ok to re-enable Wikidata Recent Changes integration on Commons. Let's reenable it and monitor if everything is ok.
    • Task
    When I open my watchlist in Desktop Mode on my iPhone, the text will sometimes oscillate between two different sizes. This is reproducible, but intermittent, and it usually goes away after a refresh. Example: {F10056681} This happens with MobileSafari on an iPhone SE running iOS 11.0.2. It has happened for a while, but I hadn't gotten around to filing a bug report.
    • Task
    While this won't be useful for Wikipedia, it will help people who write extensions that run on corporate wikis. As far as I can tell there is no standard method to get the watchers and this is useful information for tools like CategoryWatch.
    • Task
    I know it has been decided not to have tags exclusion because "it is complicated" (probably because of {T166618}?), but I'm creating that task to have clarifications about that. Also when the possibility to exclude some filters will be available, you can be sure users will ask to have it for everything. :) [[ https://www.mediawiki.org/w/index.php?title=Topic:Twybdgtsiu51urir&topic_showPostId=tx3crn8nx05be0bg&fromnotif=1#flow-post-tx3crn8nx05be0bg|Following this discussion]], imagine if a wikis has 79 tags: you have to select 78 tags to display all tagged edits except ones filtered by a particular tag. This is not simple. Another solution is to have a filter that would filter "all not tagged edits", so that people can select a little set of specific filters and add all others. There is already a way to exclude Namespaces, which could be an inspiration. However, this system is binary: you can include namespaces OR exclude them, but it is not possible select some but exclude others.
    • Task
    Hi. There is a new unwatch "x" button in watchlist. Great job, but could you please move it elsewhere in the line? It's too close to group mode "expand group" button, and can't be pressed unintentionally, especially in mobile touchscreens. For example, after the timestamp before the page name, or some another position. Thank you.
    • Task
    In Preferences, users will eventually discover [] Add pages and files I edit to my watchlist They will say that is a great idea, and enable it. But then they will say "what about all those pages I edited when it was unchecked? I wish Contributions had (solid) stars next to pages that are in my watchlist, so I can tell which of my Contributions aren't in my watchlist already (and perhaps even click on empty stars right there in Contributions to add them to my watchlist!)"
    • Task
    Patrollers on client wikis will likely want to prioritize patrolling of changes to Wikidata entities that are most relevant to their client wiki (e.g. used a lot). Similarly, Wikidata patrollers will likely want to prioritize patrolling changes to Wikidata entities that affect many pages on many client wikis. We can use nuanced entity usage information to help prioritize these changes for patrollers.
    • Task
    Once we have (LINKME: more nuanced usage tracking), we should be able to use it to direct patrollers' efforts more effectively. E.g. we can make sure that only changes that affect the rendering of a page show up on a users' watchlist (T90436) and we can direct patrollers' attention to changes that affect the rendering of a lot of pages across client wikis (T173121).
    • Task
    In old wikitext editor, I am in middle of editing and I want to mark the page for watchlisting. I click on the "star" icon. Expected behaviour: the star is coloured , the page is watchlisted, I can continue editing. Actual behaviour: a dialog is opened and I am asked to confirm the watchlisting. After confirming, the page is reloaded, **all my editing progress is lost**. This must be a new behaviour, I cannot remember this from past. I don't know who invented this, but this is not a progress, this is a serious drawback. I would gladly pass about confirmation of watchlisting in spite of uniterrupted editing. Especially when "un-watchlisting" can be done in one click too.
    • Task
    Currently the enhanced changes list uses JavaScript from module `jquery.makeCollapsible` to collapse and expand the entries. It would be nice to use a hidden checkbox and CSS to collapse the entries. This improves the performance on loading and allows using the enhanced changes list on clients without JavaScript. Inspiration from https://gerrit.wikimedia.org/r/359474
    • Task
    This version of preferences is displayed to users who have the new UX on RC page and Watchlist (either because they've opted into the beta or, down the road, because these are standard or, in the interim, a combination of the two). The many small changes made in the new design to wording and layout are too numerous to note individually. So, for layout of the page, see the screenshot below, under "**Layout**." To get correct wording, copy and paste the text in the "**Wording**" section. (Copy and paste is safest because so many, many small wording changes have been made.) For all old-style preferences, see T172757 for details about how to convert to equivalents in the new UX. =Layout, Option #1 Please consult this graphic for details about grouping and order of items, indentation and variation among text styles - All styles in the mockup are meant to indicate existing styles on the Preference page - Please note that as now, to help users distinguish among page sections more easily, vertical spacing between the last item in a section and the following section title is greater than spacing between the first item in a section and that section's own title. {F9102789} =Wording Copy final wording from [[ https://docs.google.com/document/d/1P68RN3hiQ3veKVQvhqa9suzIfBJymNYZBvwXfXfoggo/edit#heading=h.bfzo6p4c8tok | section #1 of this document ]]. =Functional Changes, Option #1 This section will single out for description only the functions and behavior which change in the preference consolidation. I.e., unless discussed, functionality will be the same as previous to consolidation. Some significant layout changes are mentioned, though you should check the Layout section below for further details. It's important to read each item carefully, because even elements that appear to be the same from one version to the next may have slightly different behavior (or titles) in different versions of these preferences. All such differences have been noted. ====Number of edits to show section - Number of edits becomes a section of its own. - As before (though it was not fully stated), this control sets the default number of changes to show on History, Contributions & Logs pages. RC page, however, is no longer covered by this control (and WL always had a separate setting). - We will set a new maximum number for all these pages of 500. - The header reads "Number of Edits to show on History, Contributions & Logs" ====Revision Scoring on Contributions page section - On ORES wikis, Revision Scoring becomes its own section, - This section, which controls the "classic ORES" features, appears on ORES-enabled wikis only. - The controls apply to all pages on which Classic ORES is available. On this version of preferences, this is Contributions only. - The section title reflects that: "Revision Scoring on Contributions page" - A new subline describes the controls. The subline contains the word "ORES," which links to https://www.mediawiki.org/wiki/ORES - The functions in this section have been re-ordered for clarity, and the small gray instruction text for the menu has been reworded. ====Watchlist section - All Watchlist preferences that pertain to filter settings have been removed. - The following option is defunct and is also removed: "Reload the watchlist automatically whenever a filter is changed (JavaScript required)" - Note: as now, the option "Always add pages I review to my watchlist" appears only for users who have the reviewer right. This option has been reworded, however. - [After Watchlist beta graduation, a New Filters opt-out will be added to the section; this is handled in T173542] ====Recent Changes section - PRIOR TO RC PAGE GRADUATING FROM BETA -- The Recent Changes preference section contains no preference options. -- It includes only a notice to users that "Recent Changes filter preferences can now be managed on Recent Changes itself...." [see "Wording" document, link below, for full and final wording]. --- If possible, this notice will be preceded by a bookmark icon. - AFTER RECENT CHANGES BETA GRADUATION -- The notice about how preferences are managed on RC page itself is still displayed. -- In addition the New Filters opt out language and check box (T168376) are displayed. ====Pending Changes - No changes were made to this section. - (As now, there is a preference that shows u only if you have the reviewer right: Show the difference between the accepted and latest revisions when viewing the latest pending revision)