✅ the Media settings dialog appears, but the filename field is not editable as expeted

No affordance for edit is displayed

@Esanders, In trying to test this, the Edit button does not do anything. Nothing in the console as well.

In T344173#9090719, @matmarex wrote:

Response after:

{
    "errors": [
        {
            "code": "internal_api_error_MediaWiki\\Rest\\HttpException",
            "html": "Cannot serialize mw:Transclusion without data-mw.parts or data-parsoid.src",
            "data": {
                "errorclass": "MediaWiki\\Rest\\HttpException"
            },
            "module": "visualeditoredit"
        }
    ],
    "docref": "See http://localhost:3080/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
}

Tested on enbeta and debeta

Better aligned now:

Looks good.
Tested on iPhone SE, iPhone 12 Pro, Galazy fold

Tested on enwiki and dewiki

Tested with enwiki and dewiki

This works as expected. With double click for focusable nodes working as expected.

That makes sense.

In T337653#9044067, @Esanders wrote:

{F37149922}

This file is not attached.

Do the screenshots capture the desired behaviour?

Before fix:

In T338145#8919423, @EAkinloose wrote:

@Esanders This is still left aligned. Am I missing some testing steps?

Testing on https://en.wikipedia.beta.wmflabs.org/,

• open VE
• interract with the toolbar and toggle width

Do I need to switch anything on/off?

Notifications appear once per action triggered

An existing CR for this is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/929770.

In T336639#8926182, @matmarex wrote:

In T336639#8919831, @EAkinloose wrote:

❓ When editing in source editor, it scrolls all the way to the top. Correct me if I am wrong but from the Transitioning from reading into editing part in T296910 , that seems to be expected.

Yes, that's expected, we didn't manage to implement a way to match the scroll position between the two editors. Thanks for testing it.

This task is good to be verified. Thanks for clarifying.

In T337438#8919616, @matmarex wrote:

Yes, that's expected. Actually supporting these pastes would be a more difficult task (but it might be magically supported when everything is switched over to Parsoid).

✅ Page doesn't reload
✅ viewport/content movement is minimized for VE
❓ When editing in source editor, it scrolls all the way to the top. Correct me if I am wrong but from the Transitioning from reading into editing part in T296910 , that seems to be expected.

@matmarex, I don't see the image when I pasted it. Is that the expected behaviour?

This works as expected. However, I observed the following:

In T338145#8919504, @matmarex wrote:

It's waiting for an OOUI release. Sorry, that's my bad, I didn't look which code repository this change was in.

@Esanders This is still left aligned. Am I missing some testing steps?

In T333476#8834241, @matmarex wrote:

In T333476#8799029, @EAkinloose wrote:

❓For mobile, it takes me to the talk page and I have to scroll down to see the newly created topics. Also they are not highlighted. See behaviour.

Filed T336190

Observations grouped by namespaces
Wikipedia

✅ Remove the language menu from the sticky header on Talk pages (and any other pages that show the compact version of the language menu)

✅ Add Topic button and language menu appear in the same order

In T317035#8590357, @EAkinloose wrote:

Only one new topic tool opens as expected. See

However, I get stuck while trying to switch between edit and add topic when I have a draft that is pending save. See 00:10 in https://photos.app.goo.gl/YzJ7VoL9P31tyPFt5

✅ Link provided by collation of multiple new topic notifications takes the user to the newly created topics with the description highlighted

In T334727#8788080, @matmarex wrote:

@EAkinloose That's unrelated to the change. It looks like you were testing on the main page of the beta ruwiki (https://ru.m.wikipedia.beta.wmflabs.org/wiki/Заглавная_страница), and there's a special behavior for the main page, where it doesn't get the normal tabs at the top. If you test on a regular article (e.g. https://ru.m.wikipedia.beta.wmflabs.org/wiki/Википедия), things should behave as expected.

That said, something is wrong with this behavior… once you're on the discussion page, there should be a button to return to the article, replacing the button to view the discussion. Or maybe the talk page of the main page should get normal tabs. But having a button to view the discussion on the discussion page is definitely wrong :) Can you file a bug about this?

@matmarex
For clarification: the Discussion button below is displayed as an ingress to the discussion tab since the TopTabs aren't shown anymore. Is this behaviour expected? The button replacing the Top Navigation?

It takes about a second or 2 now. That's an improvement but is the target here milliseconds?

No issue

In T328121#8615703, @matmarex wrote:

QA steps:

• Visit a page in Vector 2022
• Open the visual editor
• Toggle limited content width using the tiny button in bottom-right corner
• Check that the position and width of the visual editor toolbar reflects the new position and width of the page content
• Also repeat the above: when starting from limited vs unlimited content width when opening the editor; when scrolled down on a long page and opening the editor from the sticky header