Nothing seems actionable here, closing.

Is there any chance that this feature will be implemented sometime soon?

We recently switched from GitHub / HuBoard to Phabricator, and overall I'm really happy, but the one thing that I (and the other engineers on my team) sorely miss is the ability to change columns from within the task. It is really awkward to comment on the task but not be able to change columns without swiching back to the workboard.

I spent like 20 minutes on this in the redesign and couldn't figure it out.

What is your expectation of what should happen here? This doesn't seem like a Workboard issue, just an issue with menus in general. Should we just automatically close any open ones if you change your mind and open a different one?

It also doesn't go away on desktop, I just never tried before (Latest Chrome, android and windows).

Works for me on the iPad Pro. Thank you!

Seems OK for me on a physical iPhone 4s.

This is live on this server (secure.phabricator.com) -- let us know if you're still seeing issues. Seems OK for me on a physical iPhone 4s.

Yep and to be honest this huge iPad is fairly desktop-y. The first time I saw it I kind of had to look twice to make sure it wasn't some run away item from Alice in Wonderland that had snuck into my reality.

D15136 distinguishes between "touch-device" mouseovers and "mouse-device" mouseovers rather than relying on device detection, since the screen resolution of the iPad Pro is apparently a billion pixels by a trillion pixels and device detection is clearly increasingly hopeless.

I gave this solution a quick whirl and it works. It preserves mouse over behaviour in regular browsers, and removes the need for double tapping in iOS (while still getting the selection highlights). Let me know if you'd like a patch or if you prefer your device detection approach.

Yeah. On a pure touch device, mouseover is not the most useful event to listen for when it comes to highlighting rows.

Nice work! I arrived at the same conclusion shortly after you did.

I have found the bug. For iOS Safari to send a click event, the handlers of mouseover and mousemove must not change the document content. (Presumably to allow a touch user to reveal things that require mousing over, without actually clicking things.)

I can reproduce this on my iPhone 4s which correctly selects 1-up mode, so I agree that this is probably not a duplicate of T9969.

Okay I don't think it's related to the 1up vs 2up renderer. Reading the source code I found out that the "1up" renderer seems to be triggered for certain screen widths. So I used an iOS Split View to reduce the width of my browser until it was fairly narrow, and as result I got a unified diff instead, which I believe is the "1up" view.

Not sure what the "1-up renderer" is but if it's 1 vs 2 columns, that's not the problem really. The formatting of the diff is fine (it's a large, desktop size screen).

Maaaybe an issue with how we detect and decide to use the 1-up renderer? cc @epriestley

I think this is a duplicate of T9969. Basically between Safari 9.1 and 9.2 somewhere, it now reports a "diff" page to us as a desktop page, where if we normally detect being on a phone or tablet, we do not trigger tooltips, hovers, etc.

In T10229#155876, @chad wrote:

I can't say I have tried every button, but the same behaviour affects even buttons without tooltips.

Do you mind testing other buttons, by other buttons I mean any form anywhere on Phabricator that is not on the "diff" page.

In T6027#135704, @isfs wrote:

Would it perhaps be simpler if instead of developing a "Change columns" UI, actions can be added to move columns, something more along the lines of what I mocked up for T9280, i.e. a simple action with two parameters, rather than a monster action with parameters for all existing boards?:

If you want to move the task on multiple boards (which I imagine is relatively, if not absolutely rare) you would just add multiple actions. The order of the actions is clear, even if not mutable.

Broadly, if comments have the new "stacked action" UI (an "Add Action..." dropdown, allowing you to take multiple actions at once), the expectation is that they support the new drafts too. This includes Maniphest at HEAD.

Can't reproduce anything here, with Workboards/Mobile. If this was a real bug report, please follow Contributing Bug Reports and re-open.

Are you testing Phabricator or trying to file a bug?

I've marked D14637 as fixing this.

To be fair, the "description" of T9065 is just an image, which isn't helpful for searching.

Ach! Just FYI I missed T9065 with a search for "mobile diff"

Happy to help with conversions if that's how this gets solved.

Actually I guess (2) already got pretty much fixed in D11340.

There are broadly two issues here:

Android 4.4.2 (also happens on 4.1 but I know it's too old, and I will replace this 4.1 next month...)
Google Chrome for Android 46.0.2490.76

https://secure.phabricator.com/book/phabcontrib/article/bug_reports/ has a bit more detail, we're trying to get the full steps to reproducing bugs when filed now so we can reduce back and forth time.

I don't know what you're screenshot is supposed to tell me. Can you be more specific about reproduction instructions (OS, Browser, expected results). This behaves as expected on iOS Chrome and Safari.

It would be great to have this in Maniphest - whatever way there is...

I would like to confirm that it would be a great addition to be able to move a task to a different column within the edit mode.
Especially if you're working within the workboard view, it would be efficient to not need to explicitly move the task to another column, right after the task has been edited within the inline popup (or vice versa).

This is fairly straightforward but blocked on T9132, which is prioritized elsewhere. This is likely to be completed adjacently with T9132 anyway.

That would make this function at least useable in some way, even if it would be a bit complicated if a task has several (5+) projects assigned (which is, what you said already, very rare).

Would it perhaps be simpler if instead of developing a "Change columns" UI, actions can be added to move columns, something more along the lines of what I mocked up for T9280, i.e. a simple action with two parameters, rather than a monster action with parameters for all existing boards?:

This might be a more general issue:

gotcha, I can repro these and fix easy.

I saw this on Q100 and Q105. On some questions everything did seem to layout properly, such as Q114. If all content is supposed to wrap (to not require horizontal scroll) then it might be the long links on those Questions.

What question is it specifically?

Oh, maybe just Safari Mobile bug?

I noticed T9278 was landed and checked here at secure.phabricator.com, so I thought I'd check this out on mobile again. I cleared website history & data from Safari and it looks like this was still happening. Was this put up on the install yet?

We'll give you a badge if you complete the task. The problem is easy tasks are easy, so we just usually do them.

Lol

Oh yeah, I'm not sure if this install has that patch. It seems ok on my sandbox, but we can verify.

I noticed this here on secure.phabricator about an hour ago. I haven't tested it on my own install yet (which was only updated to stable on Saturday).

I presumed this was fixed with D13904 but sounds like it didn't get all cases?

Sorry this looks like dup of T9239. I missed it in the search.

You're not supposed to scroll, pre should be wrapping.

Well, due to recent shortages of warm expressions of user gratitude, the upstream has had to resort to providing their own positive feedback. They achieve this by self-awarding cool-looking badges for commits.

What does Badge Awarded mean?