The links (not the suggested links) can be right-clicked and opened in another tab/window. It seems to me perfectly fine. I added to signal that there are, in fact, some ways that users are still able to interact with a content.
Also, tapping on an article's templates, images and on the footer will bring up disabled template editor, media settings and page options window repectively.
Media Settings Page options Template editor This should be fixed as part of initial release imo as this is an important main requirement to not enable opening other cards, especially on Desktop where the add links card is no fixed as an overlay on the entire page. Equally, it should *not* be possible for all add link inspector cards to be closed.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| AddLink: Disable unneeded context, tool, and command items | mediawiki/extensions/GrowthExperiments | master | +65 -7 |
Related Objects
Related Objects
- Mentioned In
- T281648: Add link: VE elements overlapping context item on desktop
T281463: Set background color to recommended link context item
T278600: Pre-deployment QA: "Add a link" - Mentioned Here
- T267706: Add a link in VE: Use a permanent context instead of VE's built-in context
T269638: Add a link: Suggestions mode
Event Timeline
Comment Actions
@RHo @MMiller_WMF I'd like for us to discuss this before we do any work around it. As far as I can tell, to disable interactions with the various dialogs and tools available in the VisualEditor surface, we'll have to manually specify each one that we want to block, which is kind of tedious and error-prone as there are a lot of them, and other extensions (e.g. Cite module) can register more tools.
On top of that, it may be tricky to disable the highlighting that appears when mousing over or clicking on a context item (e.g. the references section), even if we can block the opening of the dialog associated with that particular context item.
From a product perspective, it seems like removing all the other tools and dialog interactions moves us farther away from the goal of introducing the standard editing environment to the user. Could we perhaps consider instead providing a visual cue to the user that the VE is in read-only mode (or in suggestion mode, so the only thing they can do are the link suggestions) when these dialogs are opened? Or alternatively, doing nothing with this task for the initial release?
Comment Actions
@Tgr's idea from standup: capture click events on the document and stop propagation if the click is not one of our elements
Comment Actions
That could work potentially. I guess my concern is more from a product perspective than a technical one (hiding most of VE functionality from curious users). From a technical perspective, would prefer to do something with this after we've done the instrumentation and remaining bug fix / feature tasks.
Comment Actions
@kostajh @mewoph -- should we continue to have this task, given that the thinking and work is happening in T267706: Add a link in VE: Use a permanent context instead of VE's built-in context?
Comment Actions
Hi @MMiller_WMF I think this should be kept separate even though they are related. Once a permanent context is used for the link inspector, nothing is stopping the user from clicking outside the link inspector (and on elements other than the link recommendations) so it's possible that existing context items would still show up.
Here's an example from my permanent context item prototype (ignore the positioning for now) where the link inspector and template context item are both present:
Comment Actions
@mewoph -- right right, sorry -- I forgot about the distinction between these two issues. They are both about context items, and I got confused.
Comment Actions
I'm marking this stalled until we wrap up the work in T267706: Add a link in VE: Use a permanent context instead of VE's built-in context. In theory maybe there is not going to be overlap, but I'd like to avoid rewriting code to implement this.
Comment Actions
Change 683557 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] AddLink: Disable unneeded context, tool, and command items
Comment Actions
After unregistering all the context items, clicking on an image still does something; at least the focus behavior changes. (If you click on an image, then click on a link suggestion, the suggestion won't activate.) Not sure if that's worth fixing.
Comment Actions
Change 683557 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] AddLink: Disable unneeded context, tool, and command items
Comment Actions
I can't reproduce that. I was just looking at https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Catch_dog&veaction=edit&getasktype=link-recommendation&geclickid=blah on both mobile and desktop. @Tgr if you can still reproduce it, could you please file a task about it?