Thanks, @Etonkovidova. FYI @RHo.

@ovasileva -- please let me know if we'll need to adjust our GuidedTours or if this can be fixed on your end. I'm not sure if there are other GuidedTours out there (not administered by our team) that could get thrown off by the new user links.

@MMiller_WMF it's very likely this will require a change in GuidedTours from how we've handled this in other extensions.

@Etonkovidova could you provide some replication steps for how to see this? I've not used the extension before so am not clear on how to replicate this to investigate further.

In T287646#7245115, @Jdlrobson wrote:

@Etonkovidova could you provide some replication steps for how to see this? I've not used the extension before so am not clear on how to replicate this to investigate further.

Steps to reproduce for Homepage tours:

• enable both options in Special:Preferences-User profile (the first tab) - Newcomer homepage
• enable in Special:Preferences-Editing - Enable the editor help panel option
• the following in the Console will trigger Homepage tours

new mw.Api().saveOptions( {
    'growthexperiments-tour-homepage-welcome': '0',
    'growthexperiments-tour-homepage-mentorship': '0',
    'growthexperiments-tour-homepage-discovery': '0'
} ).done( function() { window.location.reload() } );

I can't reproduce the exact error; to me, these guiders just appear in the middle of the page, detached. The reason for that is that #pt-userpage, used for targeting that link in these guiders, but also all kinds of tools and gadgets, has been renamed to #ca-userpage. ca is normally reserved for content tabs (like the talk page tab) vs. pt for personal toolbar items, so I assume this was by accident.

(F34568633 even has the order of the toolbar items scrambled. No idea how that would happen.)

Notice

• the task screenshots are done on betalabs. testwiki wmf.16 looks different, I'll re-check betalabs and edit the descripion.
• the popups lost their pointing on testwiki wmf.16. The text provides sufficient info to instruct users where they should click. The quesiton is: is tit acceptable behavior or not?
• the real issue is with Mentor reply

Comparison of Homepage tours - present production (enwiki wmf.15) and testwiki wmf.16 with New user links.

enwiki wmf.15	testwiki wmf.16 with New user links
on a random page
on the Homepage
Mentor reply

In T287646#7247499, @Tgr wrote:

I can't reproduce the exact error; to me, these guiders just appear in the middle of the page, detached. The reason for that is that #pt-userpage, used for targeting that link in these guiders, but also all kinds of tools and gadgets, has been renamed to #ca-userpage. ca is normally reserved for content tabs (like the talk page tab) vs. pt for personal toolbar items, so I assume this was by accident.

As per my previous comment, I'll re-check betalabs, esp

The RecentChanges guider points to #pt-preferences, which is invisible with the menu closed, so it seems to float in nothingness. I guess that guider needs to be updated to point to the dropdown and have slightly different text. The relevant code is WikimediaMessages > modules/rcfilters-intro-tour.js.

In general, since this update changes a number of personal toolbar links behind a dropdown, I think it would be worth grepping for the relevant ids in the codebase to see if anything is affected, and to communicate to tech ambassadors, Tech News etc that gadgets might be affected.

The other thing I'd check (not related to this task) is whether mw.utils.addPortletLink, which is used in a ton of gadgets, remains functional, especially when adding inside the dropdown.

I'm not seeing a pokey arrow in the replication steps on desktop resolution (only when I shrink the window):

Do I need to do anything else to see it, or is that part of the bug?

The other thing I'd check (not related to this task) is whether mw.utils.addPortletLink, which is used in a ton of gadgets, remains functional, especially when adding inside the dropdown.

This continues to work. It was part of the specification for this feature.

The reason for that is that #pt-userpage, used for targeting that link in these guiders, but also all kinds of tools and gadgets, has been renamed to #ca-userpage. ca is normally reserved for content tabs (like the talk page tab) vs. pt for personal toolbar items, so I assume this was by accident.

When ca- appears it's usually because legacy code has been invoked due to a non-existent ID. The new ID should likely be pt-userpage-btn. There are two user links now in the page, so we'll also need to adapt this code to point to the visible one.

In T287646#7247575, @Jdlrobson wrote:

I'm not seeing a pokey arrow in the replication steps on desktop resolution (only when I shrink the window):
Do I need to do anything else to see it, or is that part of the bug?

That's part of the bug, yes. The guider doesn't find the element it should attach to so it falls back to a generic dialog appearance.

In T287646#7247542, @Tgr wrote:

The RecentChanges guider points to #pt-preferences, which is invisible with the menu closed, so it seems to float in nothingness. I guess that guider needs to be updated to point to the dropdown and have slightly different text. The relevant code is WikimediaMessages > modules/rcfilters-intro-tour.js.

RecentChanges landed with the Growth team on the maintainers wheel of fortune so we should probably do that. What do I need to do to enable the compressed personal toolbar locally? I skimmed Skin:Vector but none of the settings seemed relevant.

$wgVectorConsolidateUserLinks = [ 'logged_in' => true, 'logged_out' => true ];

This is a temporary feature flag so we don't advertise those on MediaWiki.org

Change 708871 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Update user page link element ID

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

Not sure how to set these tours up, but the above patch changes the element ID to something more logical per @Tgr's suggestion.

For the user link, we'd need to point the arrow to pt-userpage AND pt-userpage-2 (after above patch) depending on which is visible. Is the code smart enough to allow multiple elements to point at?

For the hidden links, perhaps this could be as simple as forcing open the dropdown menu using:

$('#p-personal input').prop('checked', true)

?

I don't understand why multiple IDs are needed. In what situation would both userpage links be rendered?

GuidedTours tours take a jQuery selector, so they should handle a list of ids fine. I'd expect other things to break though. Just from a quick search, tests for Wikibase, WikibaseMediaInfo and core reference it, the Gravatar extension styles it.

In T287646#7247714, @Jdlrobson wrote:

For the hidden links, perhaps this could be as simple as forcing open the dropdown menu

That would be one way, or it could just point to the main menu botton (I think we do the same in Minerva).

What's the best way to detect that this is needed? Is the body.skin-vector-consolidated-user-links class stable?

I don't understand why multiple IDs are needed. In what situation would both userpage links be rendered?

So there are actually 2 user menu buttons now in the HTML - one in the dropdown (shown to mobile users, viewport < 500px) and one outside (shown when resolution is large enough e.g. desktop). They look different so it didn't make sense to use the same ones and swap them via JavaScript so we use CSS to toggle between the two.

What's the best way to detect that this is needed? Is the body.skin-vector-consolidated-user-links class stable?

The skin-vector-consolidated-user-links is temporary so I'd suggest using vector-user-linksclass which is tied to the component and not going anywhere.

Change 708871 merged by jenkins-bot:

[mediawiki/core@master] Update user page link element ID

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

Change 709240 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Fix guider positioning

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

With the patch:

old personal toolbar
compact personal toolbar
compact w/ narrow screen

On a sufficiently narrow screen things get messed up, but that's not related to either the patch or the Vector change - the guider code is just not very sophisticated.

Change 709241 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikimediaMessages@master] Update recentchanges/watchlist guided tour for Vector changes

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

Change 709241 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Update recentchanges/watchlist guided tour for Vector changes

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

Change 709240 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Fix guider positioning

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

Thanks for the reviews, @Jdlrobson!

From a quick search for the attachTo keyword used for guider positioning, the only other affected guider seems to be for Flow opt-in, so we should probably fix that as well.

In the longer term, it would be nice to migrate the guider library in GuidedTours to Vue, and improve its diagonal positioning and tip positioning logic in the process. That would be a breaking change though that would require checking and possibly adapting all code locations where a guider is used.

I tested the WikimediaMessages change with:

new mw.Api().saveOption( 'rcenhancedfilters-seen-tour', 0 );
mw.loader.using('ext.guidedTour.tour.RcFiltersIntro').then(()=>location.reload())

after the change I got the following for WikimediaMessages:

and for the GrowthExperiments change:

@RHo with the current patches (see screenshots above), the guider points to the user toolbar dropdown whenever it references something inside it (the username / user page link, preferences, or beta settings), and the text of the guider tells the user which link to click. Is that satisfactory? As Jon said, the other option would be to programmatically open the dropdown and point the guider (with 'rightTop' tip positioning, I guess?) to the specific item.

In T287646#7252486, @Tgr wrote:

@RHo with the current patches (see screenshots above), the guider points to the user toolbar dropdown whenever it references something inside it (the username / user page link, preferences, or beta settings), and the text of the guider tells the user which link to click. Is that satisfactory? As Jon said, the other option would be to programmatically open the dropdown and point the guider (with 'rightTop' tip positioning, I guess?) to the specific item.

Hi @Tgr - do you mean the alternative could be something like the following:

I do think that would be preferred. But at the same time the user links avatar icon menu without the separate user name link only happens at narrower browser widths, so it's not terrible to only point to the closed avatar icon menu item for now. Spoke with @ovasileva and we would be fine to have this done as a follow up.

@Etonkovidova - since reproduction steps are a bit complex, do you think you could help us with the QA for this task?

Change 709937 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/Flow@master] Fix guider for Vector consolidated user links

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

Test steps for the Flow patch: make sure your talk page has Flow enabled, set <wiki id>Flow_optIn_guidedTour cookie to truthy value, load your talk page.
Normally it's only shown right after enabling Flow on your talk page via the beta feature. As such, it's rare enough that I don't think it needs to be backported.

In T287646#7252937, @RHo wrote:

Hi @Tgr - do you mean the alternative could be something like the following:

I do think that would be preferred.

I tried doing this, but at the widths where the userpage link gets moved into the dropdown (<720px) the guider does not fit into the space to the left of the dropdown, and ends up overlapping it and looking horribly, so just pointing to the dropdown opener icon is more useful.

Pointing to items inside the dropdown would make sense for items other than the userpage (those are always inside) on wider screens, but for GrowthExperiments those aren't used - only notifications (which is never inside the dropdown) and userpage (which is only inside for narrow screens). Flow and WikimediaMessages do use them but I don't think those guiders are too important for the new user experience.

In T287646#7258092, @Tgr wrote:

In T287646#7252937, @RHo wrote:

Hi @Tgr - do you mean the alternative could be something like the following:

I do think that would be preferred. But at the same time the user links avatar icon menu without the separate user name link only happens at narrower browser widths, so it's not terrible to only point to the closed avatar icon menu item for now. Spoke with @ovasileva and we would be fine to have this done as a follow up.

I tried doing this, but at the widths where the userpage link gets moved into the dropdown (<720px) the guider does not fit into the space to the left of the dropdown, and ends up overlapping it and looking horribly, so just pointing to the dropdown opener icon is more useful.

Pointing to items inside the dropdown would make sense for items other than the userpage (those are always inside) on wider screens, but for GrowthExperiments those aren't used - only notifications (which is never inside the dropdown) and userpage (which is only inside for narrow screens). Flow and WikimediaMessages do use them but I don't think those guiders are too important for the new user experience.

Right, I thought it might get a bit messy and not worth pursuing right now considering it is for the narrower widths and pointing to the user dropdown seems good enough for that case. Earlier I agreed with @ovasileva that it would be a follow up task, but seems it isn't worth doing that. Instead, we could just monitor for any noticeable drops in homepage discovery, however unlikely – FYI @nettrom_WMF and @MMiller_WMF.

Thanks for fixing this, @Tgr! And yes, @RHo, skipping that change and just monitoring sounds fine to me.

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

Follow the steps from T287646#7247313
Enable both options in Special:Preferences-User profile (the first tab) - Newcomer homepage
and in Special:Preferences-Editing - Enable the editor help panel option
the following in the Console will trigger Homepage tours

new mw.Api().saveOptions( {
    'growthexperiments-tour-homepage-welcome': '0',
    'growthexperiments-tour-homepage-mentorship': '0',
    'growthexperiments-tour-homepage-discovery': '0'
} ).done( function() { window.location.reload() } );

✅ AC1: When username is not collapsed in the User Links menu, the popup should point to the center of the username.

In T287646#7272947, @Tgr wrote:

There is still a (less important) fix for Flow needing review.

Got it. Sorry about that. In that case, I will untag the Web team's backlog from this, but feel free to ping us if there's anything from our side that's still necessary.

Thanks @ovasileva! No assistance needed, just wanted to keep it in our "needs code review" column.

Change 709937 merged by jenkins-bot:

[mediawiki/extensions/Flow@master] Fix guider for Vector consolidated user links

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