Watchlist Expiry: Update popup loading behavior when watching via star [medium]
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	ifried
	Apr 2 2020, 7:12 PM

Description

As a Watchlist Expiry user, I want the pop-up to be OOUI, so that it can generate the option to watch temporarily.

Background: This is a sub-task of T248496. Please refer to this ticket for details. The purpose of this ticket is to implement the loading of the popup, replacing Toast (current behavior) with OOUI.

Resources:

Acceptance Criteria:

The user should be able to watch a page via the star & generate OOUI message
- When a page is not being watched, the user can click the star to load the pop-up
- OOUI should be lazy loaded on click of the star, not on page load.
- OOUI pop-up should appear with success message (later augmented with expiry selection)
  - Success message: [page name] and its talk page have been added to your watchlist permanently
- The word "watchlist" in the pop-up should always link to the user's watchlist
Message should be dismissible
- OOUI popup should vanish after 6 seconds, if the user does not interact with the pop-up.
  - If the user hovers over pop-up or interacts with anything in the pop-up (or if any element inside it is in focus), the pop-up should not vanish
- OOUI popup should vanish after if user clicks outside of pop-up.
- Hovering over the popup resets that count to vanish 6 seconds after mouseout.
The user should be able to unwatch the page, via star, and see unwatch message
- The user should still be able to unwatch the page by clicking the star
- Message appears as usual with the same message (no change)

Visual Examples:

Temporarily watch a page via star, before selection made (note that this ticket does not include the drop-down, as shown in the mockup)

Screen Shot 2020-04-02 at 4.35.55 PM.png (357×956 px, 217 KB)

Unwatch a page

Details

	Subject	Repo	Branch	Lines +/-
	Replace toast with OOUI popup on watchlist message	mediawiki/core	master	+74 -10
	Ajax watch: Move JS config var to packageFiles	mediawiki/core	master	+7 -3

Customize query in gerrit

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Resolved		ifried	T248496 Watchlist Expiry: Add a popup to watch pages temporarily - BEING WORKED ON IN SEPARATE SUBTASKS
		Resolved		Scardenasmolinar	T249259 Watchlist Expiry: Update popup loading behavior when watching via star [medium]

Event Timeline

ifried created this task.Apr 2 2020, 7:12 PM

ifried updated the task description. (Show Details)Apr 2 2020, 7:18 PM

ifried updated the task description. (Show Details)Apr 2 2020, 8:27 PM

ifried updated the task description. (Show Details)

ifried updated the task description. (Show Details)Apr 2 2020, 8:35 PM

ifried updated the task description. (Show Details)Apr 2 2020, 8:41 PM

ifried updated the task description. (Show Details)

ifried renamed this task from Watchlist Expiry: Implement Loading of Pop-up to Watchlist Expiry: Implement Temporary Watch via Star Functionality.Apr 2 2020, 8:44 PM

ifried updated the task description. (Show Details)

ifried renamed this task from Watchlist Expiry: Implement Temporary Watch via Star Functionality to Watchlist Expiry: Implement Pop-up Loading & Selection Behavior.Apr 2 2020, 8:46 PM

ifried renamed this task from Watchlist Expiry: Implement Pop-up Loading & Selection Behavior to Watchlist Expiry: Update popup behavior upon watching page via star.

ifried renamed this task from Watchlist Expiry: Update popup behavior upon watching page via star to Watchlist Expiry: Update popup loading behavior when watching via star.

ifried updated the task description. (Show Details)Apr 6 2020, 5:29 PM

ARamirez_WMF renamed this task from Watchlist Expiry: Update popup loading behavior when watching via star to Watchlist Expiry: Update popup loading behavior when watching via star [medium].Apr 6 2020, 5:31 PM

ARamirez_WMF updated the task description. (Show Details)

ARamirez_WMF moved this task from New & TBD Tickets to Kanban-2019-20-Q4 on the Community-Tech board.

ARamirez_WMF edited projects, added Community-Tech (Kanban-2019-20-Q4); removed Community-Tech.

Restricted Application edited projects, added Community-Tech; removed Community-Tech (Kanban-2019-20-Q4). · View Herald TranscriptApr 6 2020, 5:33 PM

ARamirez_WMF moved this task from New & TBD Tickets to Kanban-2019-20-Q4 on the Community-Tech board.Apr 6 2020, 5:39 PM

ARamirez_WMF edited projects, added Community-Tech (Kanban-2019-20-Q4); removed Community-Tech.

ifried updated the task description. (Show Details)Apr 7 2020, 5:05 PM

ifried updated the task description. (Show Details)

ifried updated the task description. (Show Details)Apr 7 2020, 5:07 PM

ifried updated the task description. (Show Details)Apr 7 2020, 5:10 PM

• Prtksxna updated the task description. (Show Details)Apr 7 2020, 5:12 PM

Scardenasmolinar claimed this task.Apr 10 2020, 4:40 PM

Scardenasmolinar moved this task from Ready to In Development on the Community-Tech (Kanban-2019-20-Q4) board.

Change 591159 had a related patch set uploaded (by Scardenasmolinar; owner: Scardenasmolinar):
[mediawiki/core@master] [wip] Replace toast with OOUI popup on watchlist message

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

gerritbot added a project: Patch-For-Review.Apr 20 2020, 7:59 PM

After a bit of back and forth with @Catrope and examining the challenges here with an OOUI popup, Roan made a good point about at least testing whether the alternative is viable.

Here it is:

mw.notify allows not only a message, but also a jQuery object. Since that's the case, we might be able to have an easier time just utilizing the already-existing behavior of mw.notify, augmenting it with OOUI widgets internally, and then seeing whether we can control when it vanishes.

So, instead of creating a brand new OOUI popup (that will require us to manually place it, which is a bit of a challenge) we can "just" utilize the same mw.notify behavior, but instead of feeding it a single message, we feed it the DOM of an ooui widget. We can start with a label-only, and test whether that behavior supports controlling how long it takes to vanish *and* making sure it does not auto-vanish when interacted-with (so, it doesn't automatically close when something clicks inside it either)

I'm not convinced that this behavior is completely easier, honestly, but Roan's point is valid that we should probably try this out first.

I've tested this snippet in my console on mediawiki.org and it works:

var testLabel = null
var notify = null;
mw.loader.using( 'oojs-ui' ).then( function () {
    if ( !testLabel ) {
        testLabel = new OO.ui.LabelWidget( { label:'foo' } );
    }
    notify = mw.notify( testLabel.$element, { autoHide: false } );
} );

However, if we do this, we will probably need to check into adding a configuration variable into mw.notification to make it not automatically go away when clicked, because we will have interactive elements in there. Perhaps adding something like hideOnClick config, defaulting to true (so it preserves current behavior while allowing us to set it conditionally to false with the new popup.

See for reference, mw.notification code.

Scardenasmolinar moved this task from In Development to Needs Review/Feedback on the Community-Tech (Kanban-2019-20-Q4) board.May 4 2020, 5:07 PM

• Prtksxna subscribed.May 6 2020, 5:05 AM

HMonroy moved this task from Needs Review/Feedback to QA on the Community-Tech (Kanban-2019-20-Q4) board.May 13 2020, 4:25 PM

Change 591159 merged by jenkins-bot:
[mediawiki/core@master] Replace toast with OOUI popup on watchlist message

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

ReleaseTaggerBot added a project: MW-1.35-notes (1.35.0-wmf.34; 2020-05-26).May 13 2020, 5:00 PM

On StructuredDiscussion talk pages, I am seeing inconsistent popup behaviour when clicking the watch star.

Watching talk page

Visit a talk page which is unwatched and has StructuredDiscussions enabled (go to Special:Preferences#mw-prefsection-betafeatures, check "Structured Discussions on user talk" and Save).
Click the watch star. You will see the usual watch message:
Click the watch star again. You will see the usual unwatch message:
Click the watch star again. You will see the special StructuredDiscussion message:

With watchlist expiry disabled, you see the special StructuredDiscussion message when you first click watch (step 2).

Unwatching talk page

Visit a talk page which is watched and has SD enabled.
Click the watch star. You will see the SD message telling you you have subscribed to the page (even though you have not):

I can reproduce both of the above on beta, which has watchlist expiry enabled ($wgWatchlistExpiry = true).

I have not been able to reproduce either of the above with watchlist expiry disabled (on my local version).

@Scardenasmolinar I know @Mooeypoo worked on StructuredDiscussion, so she might know more about this.

@gerritbot wrote:

[mediawiki/core@master] Replace toast with OOUI popup on watchlist message
https://gerrit.wikimedia.org/r/591159

+			'wgWatchlistExpiry' => $this->getContext()->getConfig()->get( 'WatchlistExpiry' ),

From Gerrit:

This should not be output in the <head> of every production page view.

The information is static and identical side-wide. Bundle it with the module that neeeds it instead. This avoids delaying article rendering.

In T249259#6150283, @Krinkle wrote:

From Gerrit:

This should not be output in the <head> of every production page view.

The information is static and identical side-wide. Bundle it with the module that neeeds it instead. This avoids delaying article rendering.

@Krinkle that's a good point, but in this case the module is the watch star, which is loading by default everywhere. We weren't sure where to bundle that given that the status (and watch) is basically done on all page loads.

Do you have a recommendation on where to put it given that, or is it okay to leave it in the head given that it's loaded everywhere anyways, and is a state that we'd need to check wherever "watch" action (star/etc) is loaded?

In T249259#6148287, @dom_walden wrote:

On StructuredDiscussion talk pages, I am seeing inconsistent popup behaviour when clicking the watch star.

Watching talk page

Visit a talk page which is unwatched and has StructuredDiscussions enabled (go to Special:Preferences#mw-prefsection-betafeatures, check "Structured Discussions on user talk" and Save).

Click the watch star. You will see the usual watch message:

Click the watch star again. You will see the usual unwatch message:

Click the watch star again. You will see the special StructuredDiscussion message:

With watchlist expiry disabled, you see the special StructuredDiscussion message when you first click watch (step 2).

Unwatching talk page

Visit a talk page which is watched and has SD enabled.

Click the watch star. You will see the SD message telling you you have subscribed to the page (even though you have not):

I can reproduce both of the above on beta, which has watchlist expiry enabled ($wgWatchlistExpiry = true).

I have not been able to reproduce either of the above with watchlist expiry disabled (on my local version).

@Scardenasmolinar I know @Mooeypoo worked on StructuredDiscussion, so she might know more about this.

@Catrope do you know anything about this inconsistent-watch notification bug in Flow? We will potentially need to adjust Flow's watch feature to the expiry feature, but the bug that Dom's reporting above doesn't seem related. Do you know anything about this?

ifried mentioned this in T253252: Implement OOUI Pop-Up in StructuredDiscussions (Flow extension) notifications [MEDIUM].May 21 2020, 4:44 PM

In T249259#6150343, @Mooeypoo wrote:

In T249259#6150283, @Krinkle wrote:

From Gerrit:

This should not be output in the <head> of every production page view.

The information is static and identical side-wide. Bundle it with the module that neeeds it instead. This avoids delaying article rendering.

@Krinkle that's a good point, but in this case the module is the watch star, which is loading by default everywhere. We weren't sure where to bundle that given that the status (and watch) is basically done on all page loads.

Do you have a recommendation on where to put it given that, or is it okay to leave it in the head given that it's loaded everywhere anyways […]

The JS loads relatvely late and with low bandwidth priority (compared to CSS and above-the-fold HTML). The <head> is still far too high a priority for this.

The module to bundle this is with would be that same module (the watch JS module). See packageFiles.

In T249259#6158741, @Krinkle wrote:

The module to bundle this is with would be that same module (the watch JS module). See packageFiles.

Oh, I was not aware of this (is this new!?) -- awesome, we can have a followup where we change the config placement from the core one, to the module definition.

@Scardenasmolinar tagging you here because it was your original ticket; we can have this followup on this ticket (we don't need a new one, it's a relatively small change) so they go together as one-piece to QA/Product.

Change 598136 had a related patch set uploaded (by Scardenasmolinar; owner: Scardenasmolinar):
[mediawiki/core@master] Ajax watch: Move JS config var to packageFiles

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

Thanks for the feedback, @Krinkle! @Mooeypoo, I have uploaded a new patch to address this: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/598136

Change 598136 merged by jenkins-bot:
[mediawiki/core@master] Ajax watch: Move JS config var to packageFiles

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

The user should be able to watch a page via the star & generate OOUI message

When a page is not being watched, the user can click the star to load the pop-up

OOUI should be lazy loaded on click of the star, not on page load.

When $wgWatchlistExpiry = true, there is an extra bit of javascript (the new WatchlistExpiryWidget.js plus oojs-ui) that gets loaded after you click the star.

When $wgWatchlistExpiry = false, the behaviour is the same as before with respect to what javascript gets loaded (I compared my local vagrant to testwiki).

OOUI pop-up should appear with success message (later augmented with expiry selection)

Success message: [page name] and its talk page have been added to your watchlist permanently

Sure, obviously translated depending on current interface language.

The word "watchlist" in the pop-up should always link to the user's watchlist

Yes. It also includes a link to the watched page.

Message should be dismissible

Yes, if you click the popup.

OOUI popup should vanish after 6 seconds, if the user does not interact with the pop-up.

More-or-less, although I haven't timed it exactly :)

If the user hovers over pop-up or interacts with anything in the pop-up (or if any element inside it is in focus), the pop-up should not vanish

Does not vanish if you are hovering over it.

If an element is in focus, it does eventually vanish, although not straight away like it did previously or if $wgWatchlistExpiry = false.

OOUI popup should vanish after if user clicks outside of pop-up.

Does not vanish immediately.

If you click inside the popup it vanishes.

Hovering over the popup resets that count to vanish 6 seconds after mouseout.

Seems to.

The user should be able to unwatch the page, via star, and see unwatch message

The user should still be able to unwatch the page by clicking the star

Message appears as usual with the same message (no change)

When unwatching, the popup behaves the same as when watching.

In T249259#6159774, @gerritbot wrote:

Change 598136 merged by jenkins-bot:
[mediawiki/core@master] Ajax watch: Move JS config var to packageFiles

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

Previously in the <head> part of the HTML of the page, we loaded a variable wgWatchlistExpiry.

After this patch, we no longer do this.

I checked that when watching and unwatching the correct API call gets made.

Tested a few different beta sites (incl. https://ar.wikipedia.beta.wmflabs.org, https://en.wikisource.beta.wmflabs.org, https://es.wikibooks.beta.wmflabs.org) on IE11 to test compatibility and that the message is correctly translated. Also tested watching pages on a few different namespaces.

MBinder_WMF edited projects, added Community-Tech (Kanban-2020-21-Q1); removed Community-Tech (Kanban-2019-20-Q4).Jul 14 2020, 7:21 PM

ARamirez_WMF moved this task from Ready 🎬 to Product sign-off 🤘🏻 on the Community-Tech (Kanban-2020-21-Q1) board.Jul 14 2020, 7:27 PM

• Prtksxna mentioned this in T258662: Watchlist Expiry: update time period for dismissal of pop-up [MEDIUM].Jul 24 2020, 7:17 AM

The pop-up is now functional on testwiki (see screenshot example below), so I'm marking this work as Done.

Screen Shot 2020-07-31 at 2.03.35 PM.png (313×295 px, 29 KB)

ifried closed this task as Resolved.Jul 31 2020, 6:09 PM

ifried moved this task from Product sign-off 🤘🏻 to Done 🏁 on the Community-Tech (Kanban-2020-21-Q1) board.

• Prtksxna mentioned this in T259647: Watchlist Expiry: determine potential solutions for tabbing issue.Aug 11 2020, 6:09 PM

dom_walden mentioned this in T263135: Watchlist Expiry: restore previous popup when clicking watch star (StructuredDiscussions).Sep 17 2020, 2:33 PM

dmaza mentioned this in T257396: Sort out state of Watchlist Expiry for 1.35.Sep 30 2020, 10:32 PM

Maintenance_bot removed a project: Patch-For-Review.Sep 30 2020, 11:10 PM

Could you please provide a user setting for disabling this feature?

I know I could hide the widgets by using some CSS, but I'd prefer to avoid executing more and more JavaScript for features I don't use.

@Od1n Thanks for the comment! The pop-up is actually nearly the same as the old pop-up when you watch a page via star. It displays for the same amount of time before being automatically dismissed (about 5 seconds) and it can be manually dismissed the same way (i.e., click on the pop-up). Furthermore, the default selection (to watch permanently) was the same behavior before the feature was enabled. The only difference is that you now have an option to change the watch status from permanent to a temporary selection. Overall, if you watched items via star in the past, and if you want no changes to that experience, your user flow is the same. For this reason, it's not high priority for the team to make this a user preference. However, if a volunteer developer wants to share workarounds, we are happy for people to use what works best for them. Thanks!

Though personally I don't understand the need for this feature, it seems a lot of users requested it and find it useful. So that's fine :)

Just FYI, as a workaround, I managed to hide almost completely the widgets using the following CSS:

.mw-WatchlistExpiryWidgetwatchlist-dropdown-label,
.mw-watchexpiry.oo-ui-dropdownInputWidget,
#mw-editpage-watchlist-expiry {
    display: none;
}

(about .mw-watchexpiry.oo-ui-dropdownInputWidget : theoretically .mw-watchexpiry should be sufficient, but I find the classname too "generic", risk of collision with future elements elsewhere)

This CSS rule is a bit lengthy though. So it's a tradeoff "user interface clutter" vs. "user personal CSS clutter" ^^

@Od1n Thanks for the response, and I'm glad you think it's fine. Also, thanks for sharing your work-around!

ifried mentioned this in T266121: Hide the watchlist expiration option using a mediawiki based solution.Oct 21 2020, 2:50 PM

ifried mentioned this in T265716: Allow configurable default expiry time.Oct 28 2020, 11:11 PM

Krinkle mentioned this in T270141: Watchlist Expiry: Perf follow-up 2020.Dec 14 2020, 11:18 PM

DannyS712 mentioned this in T291444: Improve bundling of mediawiki.watchstar.widgets and mediawiki.page.watch.ajax.Sep 20 2021, 11:01 PM

	F31955865: Screen Shot 2020-07-31 at 2.03.35 PM.png
	Jul 31 2020, 6:09 PM

	F31724546: Screen Shot 2020-04-02 at 4.35.55 PM.png
	Apr 2 2020, 8:41 PM

	F31718249: 500px-Temporarily_watch_a_page_via_star_with_dropdown,_part_2.png
	Apr 2 2020, 7:18 PM

	F31718251: 500px-Removal_from_temporary_watchlist_(mockup_example).png
	Apr 2 2020, 7:18 PM

Watchlist Expiry: Update popup loading behavior when watching via star [medium]Closed, ResolvedPublicActions

Description

Details

Related ObjectsSearch...

Event Timeline

Watchlist Expiry: Update popup loading behavior when watching via star [medium]
Closed, ResolvedPublic
Actions

Related Objects
Search...