I no longer seem to be able to test access to ASHA. I've (re)set it to Bundle on Staging, and can see it in My Library, but even after logging out of both EZProxy and Staging I'm seeing "We are sorry, but you are not authorized to access this resource."

I see "Access provided by Wikipedia Library".

I see "Wikipedia" highlighted as our access method.

I see "Provided for you by Wikimedia Foundation".

I can download PDFs from search results which I can't download when not proxied.

I see "Brought to you by Wikimedia Foundation".

I see "Access via: Wikimedia" and "Off-Site access provided by your institution" as expected.

In T233340#8058365, @Reywas92 wrote:

Thanks to the team for implementing this! Really appreciate it getting done after being supported in the community survey! It works great on the mobile browser interface, though I'm wondering if it will also be included in the next update of the iPhone app?

Thanks! Confirming that things are looking good on preprod now in terms of the proxy URL issues. Still waiting for a response from ASHA, who are looking into the content access problems.

Turns out this was an 'us' problem.

This is now live.

Of the non-paintbrush options my personal favourite for this menu would be the color palette :)

This exploration is effectively complete - we've opted for Option A for the main menu design.

LGTM :)

In T307818#8034739, @jsn.sherman wrote:

So, there isn't a perfect solution to this issue. From OCLC:

When I managed to get static.cloud.coveo.com to proxy. I got an error about 512 SHA integrity check fails to match the expected value. The mismatched is caused likely because the proxy server is now in this exchange. Coveo's security is blocking are ability to rewrite these URL's. I do not have a solution for this issue.
Here is the error I get with the above coveo stanza added to the configuration.
It doesn't match the expected SHA-512 value
Unfortunately, there is no resolution. In order to rewrite the URL's that portion of the site would need to be in proxy. When I get it into proxy the sites security blocks access to the content.

When I tested this, I found that there is more than one entry into search, and at least one of those entry points worked as expected. I would be happy to try to find a different starting url that nudges users towards a less broken search form.

In desktop Vector I see <changeblockip> in the sidebar when on a blocked user's user page:

Wonderful, thanks for confirming!

In T310272#8020374, @aminalhazwani wrote:

@Samwalton9 I was editing and improving the content of this task and I was wondering if it might be useful for the engineering team to have a table detailing the content that should move into a modal, a sort of inventory of things that they can follow to understand what should be in a modal, and what shouldn't. What do you think?

@Huji This issue should now be fixed - can you confirm?

In T221004#8021470, @Jdlrobson wrote:

Hi @Scardenasmolinar I've asked @cjming to take a look at this. In quarter 1 (starting July), the web team is planning to standardize menu code in core which would replace this code. I'm sure Clare would be interested in hearing about pain points you are experiencing to inform that work.

Thanks all! It would be great to get this in the next Tech News, summary below:

I removed a note about "and vice versa" because I don't think we're interested in desktop->mobile switches. This can remain scoped to the mobile->desktop toggle.

This may not be working: https://meta.wikimedia.org/wiki/Talk:The_Wikipedia_Library#File_missing:_docs/suspend.htm

Testing the WIP patch via Patch Demo (on desktop and my mobile device) and it seems pretty functional to me - the arrow placement looks better than in the gif in the task description (I assume some related CSS/JS changes happened since?) and because the entire cell is interactable I didn't have any problems sorting the table. It doesn't accidentally trigger while scrolling either.

Looking good; I see this menu without AMC turned on on English Wikipedia.

Tested that the link is present and goes to the intended destination :)

We think we're going to go the opposite direction - displaying a link to Preferences on MobileOptions, which is well understood.

We posted a more extensive set of mockups and explorations detailing how we're thinking about preferences at https://www.mediawiki.org/wiki/Moderator_Tools/Content_moderation_on_mobile_web/Preferences - please take a look and let us know what you think!

Jon's point about these either being broken or skin-specific makes sense and is probably a good model for addressing this in the long run. There are certainly settings I found which seemed like they could work on mobile but don't, and others which just don't make sense for Minerva at all.

Not sure why this didn't get added by the bot:

This is more functional but has some weird behaviour/alignment issues in Chrome (desktop inspect and mobile). Gifs below:

In T308624#7987532, @Scardenasmolinar wrote:

I have created a Patch Demo to test the changes I made and they seem to be working for Vector, Monobook, Timeless, and Minerva.

We've shared some mockups for different options for how Preferences could be styled at T310007 - feedback welcome!