In T191266#4101944, @Nirzar wrote:

we might wanna get rid of borders for action toolbar simple button item borders, all together. if not then all tool borders should be B80

Looks like you found it already.

Note that the template data editor already does this, so that would be the first place to look.

Minimal test case:

{| class="wikitable sortable"
!Foo
|-
|-
|Bar
|-
|}

The root cause is broken table syntax (defining the row twice). Ideally VE should be able to handle that.

In T170001#3528142, @Niharika wrote:

@Esanders Do you think it's possible for us to take away cursor control from CM and let the browser handle it for the classic/advanced editors in the way that VE does it? CM doesn't provide a config option for that in the library and insists on handling cursor movements itself, which it is not very good at.

One option would be to bind a mousemove listener on mouseenter (and unbind on mouseleave/show popup), and use that to update the anchor position. The position should only 'lock' when the show animation starts.

Regression caused by https://gerrit.wikimedia.org/r/#/c/422955/ @DLynch

In T192392#4137334, @matmarex wrote:

The images being inserted here are these: This might be the logo of the extension (I don't recognize it, unfortunately).

These are appearing after ISBN's so I would guess some citation plugin.

Shouldn't we just blacklist all images with a data URL?

In T192341#4135500, @Schnark wrote:

Additionally, a separate "unlink" icon (i.e. crossed out variant of the current "link" icon) for removing a link would perhaps make sense.

In T191923#4134250, @IKhitron wrote:

There is a direction button in VE (under the hamburger menu / alt+shift+x), although testing it now it appears the CM functionality has regressed.
Alt-Shift-x is special:randompage

I believe you meant Ctrl-Shift-x

It varies depending on your OS

In T191823#4133872, @Trizek-WMF wrote:

Case 1:

1. visit a page
2. click on Mobile view
3. edit the page (pen icon) Result: no editor, and the ful page is not leading

In T191923#4128805, @Niharika wrote:

In T191923#4128683, @Jdforrester-WMF wrote:

We could just hard-code in to CodeMirror's code for the 2010/2006/2003 editors that it's disabled on RTL wikis, and then enable everywhere-everywhere, and so the 2017 editor would "just work"?

I didn't think you'd be the one suggesting putting in hacks, James!
I think adding a config flag would be cleaner and not much additional work, honestly. We won't be breaking things randomly for a third party wiki either (if one uses Codemirror). :)

In T191923#4133793, @IKhitron wrote:

Tried again. It works on desktop, but Alt-Shift does not work.

Is it any more or less broken than VE (in either visual or source mode)?

Which link? Do you mean 'Mobile view' while already in the editor?

data-ve-attributes means the cause is the user pasting from another article, however I can't reproduce this bug. I've looked at the codepath, and the only way for the attribute to not get removed is if the JSON didn't parse, but looking at the saved wikitext that shouldn't be the problem here. The patch above removes the dependency on the JSON parsing, but without reproduction steps, I'm not sure it will fix the issue.

We're pretty low on keyboard shortcuts (we already get conflicts), and any sequence would want to start with '[[' which would conflict with the link sequence.

I think the new cog icon is little harder to read at smaller sizes, the old version as okay:

Can you attach SVGs?

You could look into subclassing SelectWidget.

I've replaced 'arrowNext' with 'next'. The next/previous icons are rotations of the expand/collapse pair, and this action is 'collapse'. Also the arrow icons haven't been used anywhere yet (according to T141801 their usage is "Planned in MinervaNeue").

Note also that only some of the speech bubble icons have RTL variants, so in RTL it will still be inconsistent after the parent bug is fixed (T183749).

The icons provided in https://gerrit.wikimedia.org/r/#/c/425415/ use white shapes to mask out parts. OOUI icons are only supposed to contain black and transparent, otherwise they won't work against light colour backgrounds, and they won't get inverted properly.

Hmm - it looks like the toolbar popup is in a local overlay, so all we can do here is clip it to the content area.

Inspectors, in particular, are going to require the full 400px.

I would suggest partially reverting https://gerrit.wikimedia.org/r/#/c/413707/ and making the second toolbar an OOUI toolbar.

Yeah - that is the noJS mobile editor.

Testing with a monkey patch:

I was wondering before if the dialog should contain either a visual example of rich vs plaintext, or a snippet of your actual pasted content in both modes? The latter probably has more problems, e.g. when your pasted text is very long or contains almost no formatting.

Experimenting, one of the problems is DropdownWidgets clip the menu width to the same size as the handle width. We need a dropdown that behaves more like a menu tool group.

This should be addressed soon - at least in the translation view, as frontend work is now proceeding, and issues around font-size and layout are somewhat blocked on this.

I've tested with FF 59.0 and OSX 10.11 (El Capitan) and everything looks perfect on the linked page.

The z-index should be an easy fix, I'm sure @matmarex knows what to do.

I'm thinking this could be done with some small changes the DropdownWidget, such as making the handle frameless, and not changing the label when an item is selected.

This would also apply to the topic bar in Flow:

Yes, but that's a bigger piece of work. My commit was just to restore some advanced formatting in a minimally disruptive way.

Also if you are referring to some icons being different in Apex that's because they are, but that will soon change with T169890.

In T191031#4119958, @TheDJ wrote:

Also I note that the new elements don't have textual content, only a title= attribute. As such this is a reduction in accessibility from before.

That is definitely very broken table syntax, but ideally we wouldn't throw an exception.

It just goes straight up past the edge of the textarea, it is only bounded by the browser window.

VE now has an API for this (ve.dm.Surface#startAutoSave). It uses sessionStorage, as we are worried about storage limits with multiple large documents, but that could easily be switched to localStoarge - but sessionStorage is good enough for crash recovery.

In T125222#4114643, @Nirmos wrote:

Is the purpose of this task to determine what doc pages usually are called on different projects?

In T125222#4110149, @Dvorapa wrote:

cswiki should be doc, but in that system message it is correct

5 years later and IE8 is not longer a supported client.

These are either fixed or no longer valid

This is now a standard OOUI progressive button, with blue text and icon.

The above just adds 'more' to the text styling menu, which exposes the remaining text styling tools.

After: