I think it would be more consistent to remove borders from all tool groups (except menus) by default, then if individual products have use cases to add them back in they can. We could even add an API for manual spacers.

In T237019#5752618, @Volker_E wrote:

We don't do uneven px distances in our interfaces, but try to orient on an 8px base (4px is ok, 6px should be the absolute exception).

In the vertical menu the horizontal spacing is less of an issue, but I wouldn't say it looks too cramped, it's probably just a case of what you are used to. I think the benefit of having a consistent guide for others to follow outweighs that preference, for example we use the same spacing in all other OOUI components:

The FF issue was fixed in version 72. No one has reproduced this is Chrome so I'm closing. Feel free to re-open if that is incorrect.

Yep, announced in https://bugzilla.mozilla.org/show_bug.cgi?id=1577058#c22

Following on from our discussion earlier, it should be possible to warn users editing sub-references, or disable them from being editing. Parsoid will pass through the "extends" attribute in the data-mw already, so in the VE model for the referenceNode, we can look at model.attrs.extends.

Removing VE team tag. Feel free to close out @bd808

Couldn't reproduce (iOS 13.1.3). Definitely a browser glitch, because there's not sensible reason why those icons wouldn't render.

Couldn't reproduce on iOS 13.1.3:

Note - this bug only occurs when there is an error redrawing the page after save, which shouldn't happen, but I've added a fix that does the widget teardown sooner so even if the redraw fails, you won't see the abandon dialog.

This appears to be a side-effect of T241391. After saving a comment and redrawing the page, the last thing we do is remove the system abandon changes dialog, so if there are any bugs before than, that code won't run and the beforeunload handler will still be bound.

The issue here is that the highlight is positioned relative to .mw-parser-output, but that is not position:relative.

In T240639#5758939, @Tacsipacsi wrote:

For me, it doesn’t highlight at all (FF 68.3 ESR on Debian). I see

TypeError: range.cloneRange is not a function

All the Debian-8 instances have been deleted. We now have 3 instances left, all running Buster (visualeditor-test3, visualeditor-prototype3, patchdemo).

It definitely should be (and was until recently). Not sure who is responsible for keeping those services up...

This is failing quite regularly now.

Hamburger menu with 7px spacing:

VE had a similar issue with ContentEditable: T196839

In T158617#3096674, @bd808 wrote:

The suggested quick fix here is to run vagrant settings nfs_shares off to disable NFS shares and reload your VM...

With help from @DLynch we narrowed this down to a missing apparmor:

kemayo@visualeditor-test3:/srv/mediawiki-vagrant$ sudo lxc-start --name mediawiki-vagrant_default_1576514393929_92435 -F
lxc-start: mediawiki-vagrant_default_1576514393929_92435: lsm/apparmor.c: apparmor_prepare: 974 Cannot use generated profile: apparmor_parser not available
        lxc-start: mediawiki-vagrant_default_1576514393929_92435: start.c: lxc_init: 899 Failed to initialize LSM

I think it is also not possible to edit conflict with yourself, you have to test with two accounts (or one logged out).

NB we also use this control in the save dialog

Designers: Is the ButtonWidget appropriate here

(re-opening as the discussion is active)

In this example a lot of the page is corrupted because the previous edit added an unclosed table.

I think what makes this case unique is that the failure is so catastrophic. The entirety of the page (or just after the table?) gets corrupted during the edit.

@bd808 We're in the middle of migrating visualeditor-prototype2 and visualeditor-test2, but would like an extension as we have a lot of important work going on this month that needs to take priority. We should be able to get around to finish the migration next quarter. Thanks,

Being able to corrupt the entire document just because of some unbalanced wikitext elsewhere on the page seems less than ideal...

These are the default messages for AbandonEdit, which we can override:

VE seems to insert some invisible word breaks before the umlauts

Given the page can be reloaded we would need to implement LocalStorage/SessionStorage based auto-save to support that.

We need to avoid running the code on edit pages.

In Flow this is bound to CTRL+Enter

I seem to be able to post multiple replies. Is there are specific thread where this happens? Are you logged in? Can you reproduce with the developer console open and see if there are any errors or warnings in the console?

In the anon warning we say "your IP address (12.34.56.78)" however we currently don't have access to the IP address in the client. We could make this available, but I don't know if this was done deliberately?

Started on this in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/VisualEditor/+/472514/ which separates out the metadata processing so that in theory we could show the editor once just the RESTBase data had loaded. The main issue is that if the metadata request fails, or there is a revision id mismatch, we need to close/reload the editor.

It doesn't affect all pages, e.g. https://en.m.wikipedia.org/wiki/The_Irishman_(2019_film) works fine.

I don't think we should be serving JS to environments we explicitly don't trust to work correctly.

Grammarly should be disabled on VE surfaces (at least wikitext mode)

Assume this was fixed in the last two years. Please reopen if you can reproduce.

The link [[Stadskanaal#/maplink/1]] does take me to the correct page. Can you still reproduce this @Whatamidoing-WMF ?

Please re-open if you can reproduce.

We removed a bunch of annotation rendering code from NWE. If you can still reproduce this please re-open.

I've seen bug reports in the past where VE was loaded along side other content, such as the classic WikiEditor, and I imagine this is the cause. Do you remember these @Whatamidoing-WMF ?

I'm not sure it would be a good idea to run plugins that are loaded after target init. Plugins is designed to run before target init, and some plugins may depend on this behaviour. It sounds like the issue is user scripts loading too late, but that would be an issue with MW core?

The editor now loads correctly, with the appropriate edit warnings.

JS appears to still be running in Opera 12, and even 11, so either our matrix is wrong or the feature check is wrong. CC @Krinkle

Looks like the ve-active class isn't added to the body. This is the one that hides the read article.