In T414518#11527675, @ppelberg wrote:

@bmartinezcalvo: below are the refinements to the mobile prototype I think would be useful for us to explore...

Mobile UX (newcomer)

• Once people tap the "suggestions available" banner, have it disappear.

This happens for both Mobile UX (newcomer) and Mobile UX (experienced editor)

Mobile UX (experienced editor)

• Show the suggestion rail by default with any and all suggestions that have been activated in a collapsed state

happens for both Mobile UX (newcomer) and Mobile UX (experienced editor)

Mobile UX (newcomer and experienced)

• If >1 suggestion is available within the article you are editing, when you tap the "suggestions available" banner add the ability to navigate between said suggestions from within the suggestion card directly (rather than having to manually scroll the page to find it, as the prototype currently requires)
• Remove the floating 💡 button
• When people cause the suggestion card to appear (by way of tapping the "suggestions available" banner), add the ability for them to dismiss the suggestion mode card and content highlight by tapping either a) somewhere outside of the highlighted content span or b) the suggestion "rail"

Note: we'll revisit the desktop experience once we get mobile to a solid spot.

1. Tapping the entry point scrolls to the 1st suggestion available, and this suggestion card expands when scrolling to it - ✅
2. The “View suggestions” button disappears once clicked on it or once found the 1st suggestion while scrolling, where the definition of found has been changed here in this comment but was not updated in the task description.

On Desktop, Paste Check dialog remains collapsed (Not Expanded) after resolving or dismissing the Tone Check.
On Mobile, Paste Check now correctly gets deferred when Revise button was clicked in pre-save button , and it surfaces up in non-collapsed way whenever it's position in the queue is current.

I don't see any editsuggestion-used tag being applied to edits when I act on a suggestion on Beta cluster. It's also not listed on Special:Tags page.

Interesting I thought the opposite to be expected and my thinking was that as soon as I started typing or modifying that paragraph, it kind of becomes my edit in a sense that the suggestion that was applicable for the entire paragraph, has now been modified into "a new paragraph" which is an addition in the current edit session and hence it should be considered as check instead of suggestion.

This was also happening for me on this page: https://en.wikipedia.beta.wmcloud.org/w/index.php?title=Cat&action=edit&ecenable=suggestions,experimental, I see Paste checks are appearing now.

Sure, I was testing with this quoted content:

I am seeing paste check being activated for quoted content on Beta cluster, ignoreQuotedContent in config for PasteCheck: https://en.wikipedia.beta.wmcloud.org/wiki/MediaWiki:Editcheck-config.json

In T412334#11629271, @medelius wrote:

1. Technically in that situation it's a "new" dialog/widget the second time around. As such, when it's expanded, editcheck (and the instrumentation) treats that as the first expansion (and thus marks it again as "seen").

All that to say, the underlying issue is with ReferenceCheck making that dialog disappear at all - and that's being resolved in T417718.

Thanks for the thorough testing, Rummana.

Started testing this instrumentation:

The check is working correctly when duplicate links are added in the same == H2 == within a root level paragraph.

In T74949#11573549, @Esanders wrote:

Detection heuristic: a heading, of any level, is wrapped in '''

The check as implemented checks for bold inside any of the following bold-by-default contexts:

• Heading levels of h3 ("Sub-heading 1") or higher (h4, h5, ). nb h2 and h1 are not bold by default
• Definiton terms in a definition list
• Table headings

I am seeing editsuggestion-visible / Edit Check Seen tag when I expand the suggestion card during an edit session. I am not seeing this tag being applied to edit where ≥1 edit suggestion was simply visible in the browser viewport.

Either of the former, but never higher than "sub-heading 2" (because it's the first one that looks identical to bolded text)

I noticed an occurrence where I clicked "Fix" the bolded text got converted to sub-heading 1. Screen Capture:

In T412878#11579536, @DLynch wrote:

There's definitely something strange going on there. In particular, that "heading level" check that appears at the top at ~7s in which doesn't actually associate with a heading.

For the rest of it, I think it might be the use of empty headings that's making it confused. Let me go dig into that and see if I can find out why.

In T412878#11567196, @DLynch wrote:

@Ryasmeen I can't reproduce that at all -- could you perhaps record a video so I can see the exact steps you're taking?

Looks like there are some problems:

I am still seeing textmatch check being matched for ranges that're inside quotes even after setting ignoreQuotedContent:true here: https://en.wikipedia.beta.wmcloud.org/wiki/MediaWiki:Editcheck-config.json

In T410350#11530761, @ppelberg wrote:

In T410350#11402884, @medelius wrote:

I'm not seeing this consistently. After dismissing a tone check, I'm able to add some content to the paragraph and trigger a TextMatch check without re-activating the tone check. I can also add subjective (but not textmatch-triggering) content to a paragraph where I had previously dismissed a tone check, and in some cases it will re-activate a tone check.

Same here.

---

For reference:

• Text that caused Tone Check to activate:
  • "Cats are obviously the superior beings in any household, and anyone who thinks otherwise is simply mistaken. They move through the world with an elegance and self-respect that dogs (bless their chaotic hearts) can only dream of, and their selective affection feels like a hard-earned honor rather than a slobbery entitlement. A cat doesn’t beg for your attention—it permits you to admire it—and that quiet confidence is exactly what makes them so compelling. Frankly, the idea that cats are “aloof” is just a weak excuse from people who haven’t earned their trust, patience, or impeccable judgment."
• Text that caused TextMatchEditCheck to activate:
  • "white elephant"

Yeah, probably got inadvertently fixed. Not happening anymore. Thanks for checking though.

@medelius : Looks like so. I am not seeing it either anymore.

In T411114#11412142, @Esanders wrote:

The same applies on desktop. I think at some point we made this happen deliberately as we were planning on the revising state of the card being significantly different to the inital state, but we ended up with the two states being nearly identical but for the first button. Given that it probably makes sense to switch the card to the revising state as soon as the user starts typing.