Can we add a border?

In fact on my local environment, it appears to ignore base90 as being too close to white, and leaves the header bar as white.

I don't think this example matches what is happening in VE. There is a single pixel border above the toolbar, which isn't present in my screenshots. The original issue was that there was no delineation when there was no border.

Testing locally, all the JS files take 17s, whereas the handful of HTML files take 60s, so there's something wrong with the plugin. Filed upstream as https://github.com/BenoitZugmeyer/eslint-plugin-html/issues/102

Actually I was wrong there, the maps dialog is not a MediaSizeWidget, it's a DimensionsWidget. The MSW is used on the media dialog only, so this would only affect the WIP for the media dialog which hasn't been merged yet. It looks like the DimensionsWidget suffers from the same problem so I'll fix that too.

Can you add screenshots showing the before/after of editing a file page in VE/VE source mode?

Here it is with a theme colour of #eaecf0, as suggested by Volker:

It seems like the standard practice is to make the status bar a darker version of the color used for the header, would that be possible? As in:

Here is a theme colour of #eee:

(ping @Niedzielski)

Oops. Reverted: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/VisualEditor/+/461467/

Yep - this is Parsoid only. <table><tr><td>}</td></tr></table> does not round-trip.

In T204691#4599265, @alexhollender wrote:

@Jdlrobson not sure if this was intended or not, but on staging I'm seeing the status bar + the browser header as black, which is a bit intense.

The web manifest is only used for installed web apps, and the background color property is only used for the splash screen: https://developers.google.com/web/fundamentals/web-app-manifest/

It's pretty well covered by unit tests, but loading & saving VE source mode are the areas affected (or not, hopefully)

less.php hasn't been touched in two years and has 88 open issues: https://github.com/oyejorge/less.php :/

The above patch works around the issue, it is not a fix.

Any overlay that uses a header will have it blend into the status bar, so the wikitext editor at least, and I assume there are other overlays that have headers.

Caused T204749...

@brion Are you saying that's a blocker to this task?

This should probably be fixed upstream in MobileFrontend, as it applies to any overlay toolbar.

In T204428#4589299, @Cirdan wrote:

I believe we are talking about two different issues here?

Auto-save could go in the other schema (for editor life cycle events)

1 & 2 should be easy. 3 is probably blocked on T187562.

This came up in the update for mobile of MapsDialog. If that change has been merged you can just verify that the label there is not disabled.

Small note: in our code we use "textStyle/bold" instead of "textStyle/Bold" (and similarly lower case for italic/underline)

The definition list is in fact a series of templates. Accordingly we provide a way to insert content between them with an "Insert paragraph button":

(@Deskana)

It's already hacked in to be left and right aligned context-specifically.

This is actually the fault of my template-generated ref list code, not the visual diff code :/

Duplicate of T101113?

I've researched this in the past, and the answer is basically that it's currently impossible. The best I found was people guessing based on knowing the phone model & OS version, but even then it will vary with autocomplete and different IMEs.

@dchan I've separated the patch into Android/iOS versions. The Android part works fine and should be fairly uncontroversial.

Diff after monkey-patch