Help us test the restyled composer

We’re in the process of re-writing (now) & re-styling (after) the composer.

If you notice anything weird or not working here on meta only please report all UX bugs in this topic.

Note: I will be deleting posts as I fix them. Don’t take it personally. I’ll always :heart: you.


My main usecase for it is for preview, I do wonder if we should move preview down beside the Upload word. Trouble is we are so short on space there. Previewing on mobile is often something you want to do when you include images.

How about putting it after Reply, and cancel next?

Its just super tight for spacing below we can defer on this for now. Buy yeah preview and whisper is my only personal use case for the the toolbar on mobile. I know some people also use quote.

Bug wise (not new) toggling whisper is very weird on mobile, cause you feel like the button does not work.

Preview is totally broke on mobile btw, so that is the first thing that needs fixing here.

1 Like

Toggle whisper on mobile has always been a disaster even before flexbox


Selecting “toggle whisper” doesn’t work correctly anymore, I think. When you select it, the menu does not immediately disappear as it does when you select e.g. “hide details” from the same menu. You have to first click back into the composer text box for it to go away.

If you select “toggle whisper” twice to turn it on and then off again, the menu does go away again.

2 posts were split to a new topic: Normalize Input Styling across the app

Not sure if this is an issue with composer, or just from flipping back and forth between composer implementations here on meta, but this morning my composer looked like this, until I refreshed again:

Thought I’d report it in the event that there’s some caching issues that need to be flushed for a site upgrade somewhere.

Argh! The mobile composer is so problematic with the amount of variation in available space. I tested it on a Nexus 5X, Nexus 6, and Moto G and it was fine… but there’s inevitably some device/browser where it doesn’t fit.

I’m going to try using a viewport height definition for now, but I think ultimately we should make the mobile composer a separate (scrollable) page.


Why isn’t the mobile composer just a separate page? It’s already filling the screen, so there’s no real advantage to having it docked like desktop does. And I get more confused when I press the browser’s back button and the composer doesn’t close.


Here’s another variation on the mobile composer. Android 7.1.1 and Chrome Canary 64 on a OnePlus 3 in this case.

I can’t even see the top line of the comment window!

I actually find it useful that it isn’t a separate page. As it stands, I can easily scroll back up the page to copy, quote or reference something earlier in the discussion. If the composer was a separate page this would not be possible.

While you could open the composer in a new “tab”, switching between them on mobile is currently nowhere near as quick or easy as in desktop. Also, the quote function working between different tabs on mobile would be horrible…

Just to clarify, are you talking about collapsing the composer to view the post? Unless you have a tablet-sized phone, the composer itself really doesn’t function as an overlay on mobile anymore (like it does on desktop).

I think ultimately we can make the behavior feel very similar to what it is now, but the composer would just technically be on a dedicated page for mobile devices. You’d still be able to toggle back and fourth between the two with an on-page button so you can still quote/read the content. It just alleviates some issues with being able to scroll the composer and various back button/left swipe functions.


No, I’m talking about collapsing the keyboard, but keeping the composer in view, taking up the bottom half of the screen, like this:

It ends up working a bit like split screen, but without the faffing.


Ah ok, thanks that’s a good point. I completely forgot about collapsing the keyboard.


I shortened the height of the composer for non-iOS mobile devices; if you have a moment could you check it again from your phone and add another screenshot?

The compuser used to be full screen on Android – this is possible on Android/Chrome in a way that it is absolutely not on iOS. So if it is no longer fullscreen on Android, that’s a regression. See here.


This is definitely working better for me now. I don’t have on-screen navigational buttons though, so perhaps someone with those could also test?

Also, landscape is… uhm, not good?

1 Like

The forthcoming Chrome UI change to having the address bar at the bottom makes this even worse.

Scrolling down a page auto hides the address bar, it disappears off the bottom of the screen. Scrolling up the page makes it reappear.

The composer opening triggers the address bar to appear. No amount of scrolling down the page makes the address bar disappear while the composer is open.

This may be something to ignore, since it’s Canary…
Edit: for reference, this behaviour is identical in Chrome Beta 63, with the address bar bottom aligned, as well. However, scrolling down the page in Chrome “Stable/Release” 61, with the composer open, auto hides the top-aligned address bar.

Also, is it a bug or a feature that I can scroll the page behind the composer while swapping vertically on the composer text box itself?

When is this going to happen? Details?