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.

This is now deployed to this server (secure.phabricator.com) -- let me know if you're still seeing issues? Behavior seems OK in the simulator and with my physical iPhone 4s, but I don't have a fancy physical 6s to test.

Specifically, this is my best guess at what's going on:

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.

I've marked D15135 as fixing this out of a general abundance of sunny optimism.

I think D15135 actually fixes this. I can't reproduce it in iOS Simulator after applying that patch.

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).

Should the user be warned that invisible files are still attached when they remove them?

In T10233#155967, @chad wrote:

Well it was mandatory.

This is intentional. The file is visible in the UI in the edit history of the comment, and still part of the object in that sense.

For now I've modified my local copy of this file and did few changes like:

ds fd fddgfdhgh

Sorry, we don't offer support for custom development. See Support Resources and Contributing Bug Reports for details.

This now reproduces in Chrome/iOS as of Chrome 48 (they now use WKWebView like Safari does).

Well it was mandatory.

This is almost certainly something that is only confusing to entirely new users who aren't yet familiar. I'm not surprised you're not confused if you've used phabricator for a non-trivial amount of time.

I've have several thousand or so diffs in Phabricator throughout the years, can't say I've ever mistaken something I planned changes to as landable.

That would be more clear. Even better would probably be to say what is is in fact *in*. Such as:

Yes it would. I might be more explicit and say which state it actually is in.

Would this phrasing be more clear?

See also T10229 for a similar Safari/Diff Render issue.

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.

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

In T10229#155874, @aljungberg wrote:

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

Is this report on all buttons in Phabricator or just ones that contain tooltips?

Thanks for your great work too :)

Thanks for digging into this more @clippit.

There is no cache mechanism which would be cleared by adjusting configuration that is not also cleared by restarting the webserver and daemons, so it sounds like this was caused by evil spirits.

OK, dug in some more... I've eventually managed to get it sort of working. in src/future/http/HTTPSFuture.php, you have this code:

Sorry, I had locked the project field in the edit form for that user and it wasn't pulled through.

I can't reproduce this. https://secure.phabricator.com/T10224

Looking further, google auth works up until this URL is requested in my browser: https://phabricator.tvsquared.com/auth/login/google:google.com/?state=STATE&code=CODE

Here's another...

Also just seen this:

Hi, I've accidentally fixed it. I needed to copy some tickets across from the defunct system to our new live system, so I did:

Hi, I think I find the cause.

os/php ?

It works well on this site... There must be something strange on my own install...

I opened policy up on https://secure.phabricator.com/project/view/1411/ for testing.

I still can't reproduce the error. And it happens on this install for you as well?

Here is a screen record.