Actually, it seems like rel="noreferrer" fixes this. This is bizarre so maybe this is a problem with a spooky ghost haunting my computer?

F60036 now plays correctly for me in Safari.

Linux Chrome dev channel 55.0.2859.0 (64-bit) have no issues with image paste.
Seems that it is ChromeOS specific issue.

I can't reproduce this in Chrome (OS X, Version 53.0.2785.116 (64-bit)) so it may be a behavioral change in Chrome.

I'm observing same issue in current ChromeOS 55.0.2858.0 dev branch.
At the same time image paste works in Telegram web client (seems that they use contentEditable div instead of textarea)
Do you know whether it's a chrome os bug or google deprecated DataTransfer.items in new chrome's?

doesn't reproduce anymore

This doesn't appear to even to be possible in Firefox. Here's a simple example:

From the Firefox bug and this linked one:

Truly our most useful project.

Wait for it...

Happens on test account too

I tried a couple of other devices in the simulator but couldn't get a repro -- can you try this to get a JS trace?

Let me try my spam account.

Nothing unusual. Latest iPhone/iOS

I can't immediately reproduce this in iOS Simulator or on my physical iPhone 4s. What hardware/OS version are you seeing it on?

Quoting for the main page :

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

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

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