Add a direct unwatch link to entries on Special:Watchlist
Open, LowPublic

Description

Author: ui2t5v002

Description:
"and finally... a nice feature would be a possibility to remove a watched
article from "my watchlist" (in the "my watchlist" view)"

This would be very convenient.


Version: 1.23.0
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/MediaWiki_1.3_comments_and_bug_reports#Moved_Pages_drop_off_Watchlist

Details

Reference
bz424
bzimport set Reference to bz424.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Sep 8 2004, 8:09 PM

river wrote:

*** Bug 513 has been marked as a duplicate of this bug. ***

jeluf wrote:

There already is the "edit watchlist" view which allows this.

brion added a comment.Sep 18 2004, 9:11 AM

(In reply to comment #2)

There already is the "edit watchlist" view which allows this.

Yes, but it's a super pain in the ass, particularly if you've got a large watchlist that will take time to load and search through.

ui2t5v002 wrote:

(In reply to comment #2)

There already is the "edit watchlist" view which allows this.

yes but we would like it in the regular view too.

instead of trying to remember several articles we want to delete while waiting
for the page to load, etc.

ui2t5v002 wrote:

If you install Lupin's Navigation popups,

http://en.wikipedia.org/wiki/Wikipedia:Tools#Navigation_popups

you can hover over an article link and then middle-click unwatch for almost the
same effect, since no one with coding skills seems to see the necessity of this
function...

(Hopefully I can get my watchlist under 1000 again! (It's like a weight-loss
program.))

robchur wrote:

Perhaps the watchlist view and edit pages ought to be unified - there should
certainly be an unwatch link next to entries on the regular watchlist.

ui2t5v002 wrote:

(In reply to comment #6)

Perhaps the watchlist view and edit pages ought to be unified - there should
certainly be an unwatch link next to entries on the regular watchlist.

Absolutely.

For now, I've written a little script that adds an "un"(watch) link next to the
"diff" and "hist" links. I'm not really a coder and I haven't tested it much so
point out any bugs on my talk page.

Look for

function unwatchlinks()

on http://en.wikipedia.org/wiki/User:Omegatron/monobook.js and also add
something like

if(document.title.indexOf("My watchlist") == 0) unwatchlinks();

to your Main() loader or whatever. You still have to click the link and load
the "Removed from watchlist" page, but it saves some steps. If you middle click
in Firefox you can go through a bunch at a time.

If I really knew what I was doing, there would be a little link on the left of
each article in the watchlist that lets you unwatch it, and the article link
would turn gray or something to show that it was unwatched, without actually
opening any other pages. On refresh the unwatched ones would disappear. I just
learned how to do this much, though.

jeffb wrote:

Perhaps a user could set a "max number of watched items" parameter in his
preferences. If he then adds a new watched item that takes him over his limit,
the software would drop the oldest watched item from his list.

  • Bug 5300 has been marked as a duplicate of this bug. ***

blah wrote:

I'd like to endorse this ER and was about to make the same suggestion. The
trouble with the edit view is that the watchlist is presented in alpahbetical
order. I mostly want to unwatch articles if I get tired of seeing them on my
regular watchlist. I do use navpops for that, but it's still a hassle because
of the extra window it makes, and the extra clicking and mouse motions needed.
I suggest replacing the bullet at the left of each watchlist item displayed in
the regular view, with a checkbox. You'd then just check the box for each item
you want to unwatch, and finally press a "submit" button at the bottom of the page.

ui2t5v002 wrote:

(In reply to comment #12)

You'd then just check the box for each item
you want to unwatch, and finally press a "submit" button at the bottom of the

page.

The javascript unwatch links are better. Just push "unwatch" next to the ones
you don't want to see anymore, and they go away. One click is better than two
clicks and a scroll.

dartar wrote:

Any update on this enhancement from the developers?

robchur wrote:

(In reply to comment #14)

Any update on this enhancement from the developers?

"The official position was that bug 424 has not been implemented at this time."

(In reply to comment #13)

The javascript unwatch links are better. Just push "unwatch" next to the ones
you don't want to see anymore, and they go away. One click is better than two
clicks and a scroll.

The problem with unwatch links is that they clutter up the already cluttered
interface. Now, I don't personally mind that at all, compared to how useful
they are, but for something that would be enabled by default for all users,
checkboxes might be a cleaner solution.

You could still press enter rather than scrolling down and clicking the submit
button. That's one click per entry plus one keypress, which compares favorably
with my own scripts if you want to unwatch more than one entry at a time. The
AJAX solution is probably unbeatable in terms of click count, but for general
use, the checkboxes have the major advantage of not requiring AJAX or even
JavaScript at all.

  • Bug 9502 has been marked as a duplicate of this bug. ***

MediaWiki wrote:

Since nobody seems to have mentioned it yet, there's an absolutely phenomenal script on en.wp written by [[User:Alex Smotrov]]. It's located at http://en.wikipedia.org/wiki/User_talk:Alex_Smotrov/wlunwatch.js.

I've been using it for ages, and I really like the way you can have it add an Unwatch... link, which only adds the removal links if you click it first. That decreases clutter quite well.

  • Bug 12626 has been marked as a duplicate of this bug. ***

jylee wrote:

Okay, I don't know if this bug is really in line for what I was looking for, but frankly, Bugzilla isn't really forgiving in what to search for... I was looking for a way to click a button that would allow me to select all deleted pages on my watchlist and remove them off my watchlist...

Re: comment #20, would [[User:Ilmari Karonen/unwatchredlinks.js]] do what you're asking for?

(The script will only select titles that don't have existing talk pages either. As an unintended -- but probably desirable -- side effect, it will not select user pages of existing users either.)

Changing component to "Watchlist"

A while ago I found a JavaScript implementation.
Recently during my tour through wikis I found it again and 'had' to rewrite it to work with Vector (as it was kinda broken).
I took the oppurtunity to optimize it a bit and shorten it with jQuery, posted it in the Snippets section:

That can be used for people using 1.17, 1.16 or older, assuming it will be in core by 1.18+

Vssun added a comment.Sep 28 2011, 3:35 PM

This will be a very useful enhancement

Add a link to action=unwatch next to (diff | hist) in the brackets.

javaron wrote:

http://www.sociotopia.com/wiki/watchlist_unwatch.patch

^I have created a patch that adds the unwatch link to watchlist recent changes lines. Currently, system messages only has the string "Unwatch" capitalized which is not consistent with the lower case diff and hist links. I am still new to developing for Mediawiki, so I'd really appreciate it if someone reviewed my code and gave me feedback, even if the JS fix is sufficient for the time being.

I am interested in preparing a proposal to overhaul the watchlist page for GSOC. The scope of my project would include:

*a way to group similar pages into subdirectories (e.g. Special:Watchlist/GroupName)
*allowing bulk watchlist modifications (rollback/unwatch) with checkboxes
*unify the "watched changes", "view/edit" sections
*incorporate ajax for actions that don't require a page reload (if time allows)

Does anyone have additional features/bugs that they'd like to see added/fixed on the watchlist? Please provide links to bug requests if they exist.

Any other advice is appreciated - thanks.

sumanah wrote:

Aaron, can you submit the patch as an attachment here in Bugzilla? https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes has instructions. Thanks.

You should probably also email the wikitech-l developers' mailing list to get more feedback, and come into IRC -- https://www.mediawiki.org/wiki/Communication

Thanks!

(In reply to comment #26)

http://www.sociotopia.com/wiki/watchlist_unwatch.patch

Hi Aaron,

The general idea of the patch looks good. The surrounding code offers most of the functionality already. This extends it nicely to add the unwatch link.

		if( !isset( $this->message ) ) {
  • foreach ( explode( ' ', 'cur diff hist last blocklink history ' .

+ foreach ( explode( ' ', 'cur diff hist last blocklink history unwatch ' .

			'semicolon-separator pipe-separator' ) as $msg ) {
				$this->message[$msg] = wfMsgExt( $msg, array( 'escapenoentities' ) );
			}

As you mention already this re-uses the message key "unwatch" (which is used elsewhere in the interface) for the link here. We try to avoid re-using messages for different purposes as translators can otherwise not translate it properly (although it is the same word in English, for other languages it might differ). This code was written several years ago when message keys were very generic. I suggest using a key like "watchlist-toollink-unwatch". And then in ./languages/messages/MessagesEn.php add it with a lowercase message value "unwatch" and in ./languages/messages/MessagesQqq.php add a short description about where the message is used and what it does (e.g. "unwatch link on Special:Watchlist)

I was wondering about this part of the patch:

		if( $szdiff === 0 ) {
  • return "<$tag class='mw-plusminus-null'>($formatedSize)</$tag>";

+ return "<$tag class='mw-plusminus-null'>($formatedSize)<$tag>";

		} elseif( $szdiff > 0 ) {
  • return "<$tag class='mw-plusminus-pos'>(+$formatedSize)</$tag>";

+ return "<$tag class='mw-plusminus-pos'>(+$formatedSize)<$tag>";

		} else {
  • return "<$tag class='mw-plusminus-neg'>($formatedSize)</$tag>";

+ return "<$tag class='mw-plusminus-neg'>($formatedSize)<$tag>";

		}

What is the purpose of this? It appears this is a bogus change not meant to be part of the patch (it changes the 3 <span>..</span> HTML tags into double-opening without closing tags.

+ $s .= Linker::linkKnown(
+ $rc->getTitle(),
+ $this->message['unwatch'],
+ array(),
+ array(
+ 'curid' => $rc->mAttribs['rc_cur_id'],
+ 'action' => 'unwatch'
+ )

As of MediaWiki 1.18 watch/unwatch require a token. Use UnwatchAction::getUnwatchToken

javaron wrote:

Thanks for your feedback. The tag change might have been some hasty find/replace work on my part. I'm working on adding the new unwatch string and tokens to my code.

javaron wrote:

added Krinkle's suggestions

I have uploaded a new version of the patch - any comments are appreciated. Thanks.

Attached: watchlist_unwatch_040512.patch

sumanah wrote:

Aaron, feel free to get and use Developer access

https://www.mediawiki.org/wiki/Developer_access

to submit this directly into our source control system for faster review.

https://www.mediawiki.org/wiki/Git/Workflow#Getting_set_up

Thanks!

(In reply to comment #30)

Created attachment 10384 [details]
added Krinkle's suggestions

I have uploaded a new version of the patch - any comments are appreciated.
Thanks.

Thanks, nice improvement. I'll see if I can give this a try locally soon.

Someone else is of course welcome to review it instead, as well.

In the mean time, maybe you're interested in getting a Developer account (check Sumana's comment), that way you can submit it directly to the review queue.

Attached: watchlist_unwatch_040512.patch

Krinkle added a comment.EditedMay 27 2012, 11:44 PM

(Review of attachment 10384)

Index: ./phase3/includes/ChangesList.php
===================================================================
--- ./phase3/includes/ChangesList.php	(revision 112982)
+++ ./phase3/includes/ChangesList.php	(working copy)
@@ -103,7 +103,7 @@
 	 */
 	private function preCacheMessages() {
-			foreach ( explode( ' ', 'cur diff hist last blocklink history ' .
+			foreach ( explode( ' ', 'cur diff hist last blocklink history unwatch ' .

i18n file uses "watchlist-toollink-unwatch" but here it says "unwatch". Please make it match and update the array access (->['unwatch']) as well

 	public function insertDiffHist( &$s, &$rc, $unpatrolled ) {
+		global $wgUser;

No need for the global anymore. In the current git master ChangesList.php has been updated to use Context. Below you can pass $this->getUser() directly to the UnwatchAction method.

+				'action' => 'unwatch',
+				'token' => UnwatchAction::getUnwatchToken( $rc->getTitle(), $wgUser )
+			)
+		);

kpower675 wrote:

Why don't you do this with js completely... I mean if you want to make it as good as possible then make it ajax and if you want to make it ajax you kinda need js... jquery takes care of 90% of the individual browser bugs and even so, this is simple and even IE should be able to take care of this... I can give some code for this if needed.

sumanah wrote:

Aaron, what's the status on this?

abhinav.koppula wrote:

Hi,
I am new to mediawiki development and I thought of starting off with this bug.
I had 3 alternatives in mind.
1> As pointed out in Comment 34, I was thinking of handling the whole situation in Jquery. We could have an unwatch link just like (diff|hist|unwatch) and on clicking that it would simply slide up signifying it to me unwatched and behind the scenes we can have an ajax call which can take successive actions.

2> We can also think of having a checkbox for each watched item which can be "Marked" and at the bottom of the page we can have a button "Unwatch all checked items" - a procedure similar to the standard view of Gmail

3> Or should I proceed in the direction of the already submitted patch?

Please share your thoughts upon this.

I'm setting the target milestone of this bug to MediaWiki 1.22. Come hell or high water, this bug is getting resolved before MediaWiki 1.22 is released.

Krinkle: you're listed as this bug's assignee. Is this still accurate?

I'm copying a few talented people on this bug. It's still a little unclear what the best path forward here is. There's a concern that a lot of "(unwatch)" links would add clutter.

As far as I see it, the hard requirements here are that this feature:

  • be in MediaWiki core; and
  • not rely solely on JavaScript.

As the Target Milestone on this ticket has been set to 1.22.0:

According to http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072030.html "MediaWiki 1.22 is slated for release on November 30th, at the very latest."

If this is still intended to get fixed for 1.22.0, a patch is needed soon.

Removing 1.22 Target Milestone as per http://lists.wikimedia.org/pipermail/wikitech-l/2013-October/072538.html - in case anybody manages to get a bugfix into Gerrit, feel free to reapply.

Qgil added a comment.Apr 16 2014, 3:35 AM

Krinkle, do you still plan to work on this?

(In reply to Quim Gil from comment #41)

Krinkle, do you still plan to work on this?

Bump. If there's no response in a week or two, we should probably un-assign.

This comment was removed by Krinkle.
  • Bug 70924 has been marked as a duplicate of this bug. ***
Alsee added a subscriber: Alsee.Dec 26 2015, 4:12 PM

Any chance for action on this? It seems to be relatively low on the difficulty scale.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 26 2015, 4:12 PM

Any chance for action on this? It seems to be relatively low on the difficulty scale.

It's pretty easy technically but people usually do not like even minor changes being made to pages they frequently use and also this probably needs design feedback as it adds more clutter to the already cluttered watchlist.

Sn1per claimed this task.Dec 26 2015, 4:31 PM
Sn1per added a comment.EditedDec 26 2015, 4:40 PM

Could someone from Design comment on this task? How about a little 'x' icon next to each watchlist item? Without JS, the icon, when clicked, will remove the item from the watchlist and refresh the page (or something), but with JS, it replaces the watchlist item with some text, like "Item removed. Undo?" The 'x' might be more compact than a (unwatch) link, while still conveying the same meaning.

Jorm removed a subscriber: Jorm.Dec 26 2015, 7:17 PM
Qgil removed a subscriber: Qgil.Dec 28 2015, 12:29 PM
Meno25 removed a subscriber: Meno25.Feb 22 2016, 5:49 PM
Juandev added a subscriber: Juandev.Mar 7 2016, 8:03 AM

So, how we are doing with this bug? It was created more than 10 years ago and still not resolved! What is the purpose of WMF than? Why to spend time on the creation of superproctect and simillar stuff, which nonoone wants, if we are not able to hack something for community? How we are doing it easy for editors to contribute?

Izno added a subscriber: Izno.Mar 7 2016, 8:05 PM

It'd be halarious if @Legoktm responded to that question with a gerrit patch

I'll attempt an overview/summary of why this is so complicated... UX/Design-wise, these are a few aspects to decide, that inter-relate:

  • What word/icon to show for the unwatch-link?
  • Should the unwatch-link always be visible, or only on demand ?
    • The 2 scripts shown in the screenshot below, are always visible, and therefore take up more space on the screen, and can be accidentally clicked more easily. If we use this solution, then an "undo" link might be good (albeit not required). Sn1per suggests this solution, above.
    • Or we could have an on-demand function. (e.g. Add a checkbox in the watchlist-options header area, labelled "Show unwatch links for each page". Or a link which makes the unwatch-links appear dynamically) ? Or, are there technical constraints, or social reasons, such that the links must always be visible? (The User:Js/watchlist.js script used to have on-demand functionality, but that aspect doesn't seem to be working currently)
  • What happens when we click?
    • The scripts shown below, "x" and "unwatch, the link changes colour when clicked, but nothing else occurs.
    • If I use navigationpopups to unwatch a link, it opens the bubble alert, with MediaWiki:Removedwatchtext e.g. http://i.imgur.com/Zc7qXo0.png - can we have that?
    • Other comments above, discuss jQuery and AJAX solutions, which IIUC would have dynamic effects such as sliding the row up and making it vanish. That sounds more complicated than necessary.
    • Sn1per suggests above "Without JS, the icon, when clicked, will remove the item from the watchlist and refresh the page (or something), but with JS, it replaces the watchlist item with some text, like "Item removed. Undo?"" -- The latter sounds good to me, for users with JS. I don't know what the optimal no-JS solution is.

Lastly, as @MZMcBride wrote above:

As far as I see it, the hard requirements here are that this feature:

  • be in MediaWiki core; and
  • not rely solely on JavaScript.

To which I would add: I believe the primary use-case is for removing individual links; not for doing bulk removals which are probably better done in the Special:EditWatchlist or Special:EditWatchlist/raw interfaces. For this feature, we just want something simple, that also doesn't further clutter up the watchlist interface.


The 2 existing scripts that I can get to function, look like this on Enwiki:

Image showing:

  1. standard
  2. https://en.wikipedia.org/wiki/User:Alex_Smotrov/wlunwatch.js
  3. https://www.mediawiki.org/wiki/Snippets/Unwatch_from_watchlist
Dvorapa added a comment.EditedMar 13 2016, 8:01 PM

Please see similar task: T129790

lcawte added a subscriber: lcawte.Mar 14 2016, 11:04 AM

Since I was specifically pinged, here's my answer: https://meta.wikimedia.org/w/index.php?title=Affiliate-selected_Board_seats/2016/Questions&oldid=15449001#Kunal_Mehta_7

It'd be halarious if @Legoktm responded to that question with a gerrit patch

I won't be, and here's what I said in my answer:

Speaking as a MediaWiki developer, I could personally fix T2424. I estimated it would take me about 2 hours to do so. But me fixing every bug that people bring up to me doesn't scale. So I would much rather spend 4 or 6 or 8 hours of my time working with and mentoring new contributors so they can fix the bug and then future ones themselves. So let me know if you (or anyone else) is interested in working on the bug and I'll be happy to assist. Legoktm (talk) 06:51, 17 March 2016 (UTC)

Ricordisamoa added a subscriber: Ricordisamoa.

Add Comment