Thu, Jan 16
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 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:
Wed, Jan 15
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.
All the Debian-8 instances have been deleted. We now have 3 instances left, all running Buster (visualeditor-test3, visualeditor-prototype3, patchdemo).
Wed, Jan 8
Mon, Jan 6
Dec 20 2019
It definitely should be (and was until recently). Not sure who is responsible for keeping those services up...
Dec 19 2019
This is failing quite regularly now.
Dec 18 2019
Hamburger menu with 7px spacing:
Dec 17 2019
VE had a similar issue with ContentEditable: T196839
Dec 16 2019
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
Dec 15 2019
I think it is also not possible to edit conflict with yourself, you have to test with two accounts (or one logged out).
Dec 13 2019
Dec 12 2019
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.
Dec 11 2019
Dec 10 2019
@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
Dec 9 2019
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.
Dec 6 2019
Dec 5 2019
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?
Dec 4 2019
In the anon warning we say "your IP address (220.127.116.11)" 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?
Dec 3 2019
Dec 2 2019
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.
Nov 30 2019
Nov 26 2019
Nov 20 2019
I don't think we should be serving JS to environments we explicitly don't trust to work correctly.
Nov 19 2019
Nov 15 2019
Nov 14 2019
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.