Page MenuHomePhabricator

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

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)


Unwatch a page

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 updated the task description. (Show Details)
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 updated the task description. (Show Details)
ifried updated the task description. (Show Details)
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.
Restricted Application edited projects, added Community-Tech; removed Community-Tech (Kanban-2019-20-Q4). · View Herald TranscriptApr 6 2020, 5:33 PM
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)
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

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

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.

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

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

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

Watching talk page

  1. 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).
  2. Click the watch star. You will see the usual watch message:
  3. Click the watch star again. You will see the usual unwatch message:
  4. 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

  1. Visit a talk page which is watched and has SD enabled.
  2. 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.

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?

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

Watching talk page

  1. 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).
  2. Click the watch star. You will see the usual watch message:
  3. Click the watch star again. You will see the usual unwatch message:
  4. 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

  1. Visit a talk page which is watched and has SD enabled.
  2. 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?

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.

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.

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.

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

ifried closed this task as Resolved.Jul 31 2020, 6:09 PM
Od1n added a subscriber: Od1n.EditedOct 15 2020, 3:00 AM

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.

ifried added a comment.EditedOct 19 2020, 5:50 PM

@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!

Od1n added a comment.Oct 20 2020, 2:19 AM

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!