It looks like setting inputMode='none' interferes somehow with OOUI's window opening/closing logic...perhaps it changes the focused element or scroll position? I did a quick test without the link inspector & with VE loaded in standard mode. It looks like this weird behavior only occurs when opening the dialog and tapping on a surface w/inputMode='none'.
Fri, May 7
Posted a WIP patch with some improvements:
Thu, May 6
Hi @Etonkovidova which environment is this from? With changes for T281434: Add link: VE shortcut opens a regular link inspector overlapping add link context item context items for elements other than link recommendations should not be invoked.
Wed, May 5
@kostajh I wanted to clarify to behavior you're referring to. Do you mean this effect when the link inspector shifts up as the article is scrolled when tapping anywhere on the surface?
I tried to reproduce the issue in https://ar.wikipedia.beta.wmflabs.org/ and locally with "Remember my last editor" editing preference enabled but am getting VisualEditor when clicked on a link recommendation task even though my last editor was the source editor. Maybe other settings are needed to reproduce this issue?
Hi @RHo, I just posted a patch to show the suggested-edits screen for link-recommendation.
With latest changes:
Same article w/latest changes:
The floating state of the toolbar should only be applied when the page is scrolled.
Tue, May 4
Firefox Android w/latest changes:
In Firefox, the scrollWidth of the topics overlay is incorrect, it should be the same as window.innerWidth
Mon, May 3
With changes for T280129: Disable interactions with all context items except for RecommendedLinkContextItem, this issue is not reproducible.
Updated scroll behavior on desktop:
The bottom offset was added along with the changes for T281496: Add a link: virtual keyboard covers the link inspector on mobile. I'll update the top offset so that when navigating back, the annotation appears a bit lower on the page.
Fri, Apr 30
Hi @Etonkovidova, the learn more like is only shown if learnmore field is set for the task type in the wiki's MediaWiki:NewcomerTasks.json page. For en betalabs https://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:NewcomerTasks.json, it looks like this field is not present.
Thu, Apr 29
Another issue w/keyboard: when tapping on anywhere in the surface (outside of the recommended link annotations), the keyboard shows up and the link inspector is pushed towards the top of the screen (whereas with the default context item, tapping outside the link inspector should dismiss it)
The patch addresses the issue where the keyboard shows up when navigating between recommendations using buttons in the link inspector.
Wed, Apr 28
Reopening this since I was still able to reproduce this issue
Tue, Apr 27
Updated background color:
Hi @RHo, that should address it. I'll update the background color to #F4F9FF
@kostajh I'll do that as part of this work. Will also include the follow up changes from your comments
This seems to be caused by my changes to open edit mode via JS
The positioning has been implemented in my latest patchset. For desktop, one difference from the original context item is that the link inspector is now aligned with the annotation rather than positioned based on the position of the cursor. I was unable to re-use existing positioning logic from ve.ui.DesktopContext and this was a simpler implementation. The positioning behavior is as follows:
Mon, Apr 26
Fri, Apr 23
I posted a WIP patch with RecommendedLinkToolbarDialog (extending ve.ui.ToolbarDialog) with the following existing functionalities:
- accepting/rejecting recommendations
- auto advancing upon acceptance/rejection
- updating the UI based on current selection
- showing link preview
- navigating through recommendations
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.
Hi @RHo — loading the article right away should be possible. I think there will be some additional work to ensure that on mobile, when the user closes Suggestions mode, they are taken to the article's read mode rather than back to the homepage. I went ahead and created T280991: Add a link: open the article in edit mode right away — feel free to add/edit. Thanks!
Wed, Apr 21
Mon, Apr 19
I've added Please keep to as succinct text strings as possible in the translation. to the QQQs for growthexperiments-addlink-context-button-accept and growthexperiments-addlink-context-button-reject
I do see your point about how having a long 'Yes' and or 'No' could also cause further wrapping, so would we be able to provide one further flex in that case so that the buttons then left align and fit across the whole width, but any further we would clip so that the Yes No (and "..." if shown ) buttons always stay on one 1-line.