I think I got all of these, but yell if you catch any more.

(I renamed the "Up for Grabs" column to "Ready", and kicked this out since it doesn't have detailed technical instructions that a new contributor could follow like the other tasks in that column do.)

My only (mild) concern with this is that object types may become slightly ambiguous in some contexts: currently, icons are (at least mostly) unique across object types. A tag icon or a briefcase icon is always a project. A calendar icon or a cocktail glass is always an event.

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?

This was indirectly resolved by the switch to prose diffs in T7643.

This should be resolved at HEAD of master. Thanks for the report and the detailed analysis of the issue.

D15133 (making array utility functions accept any array-like object) is a possible attack on this in the general case, but I'm just going to fix this narrowly for now since it hasn't been a frequent/common/recurring problem so far. A more general approach may be warranted in the longer run.

https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/core/behavior-form.js:57
looks like it's supposed to be listening to submit, but there's no submit event being fired while in a dialog; It does fire when the same dialog is loaded as a full-page, so some magic is happening there.

As was mentioned, there was code already for detecting a hidden hash/anchor and loading older transactions/comments to allow it to be reached. Turned out it was a cinch to hook it up, which I've done in D16256.

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

From the Firefox bug and this linked one:

Affecting Wikimedia as well.

Nope. We don't add padding to the outer container, it's handled on an object by object basis.

T10433?

Yeah I think assignee is an important piece of information, but created seems not that important? And like, in terms of focusing a user's attention, the gutter feels like "this is the second most important thing to title". Like having the avatar of the user who created it doesn't feel like very useful information.

The main challenge here is in Phabricator, tasks are ephemeral wikis that tend to be community built. Knowing the author is generally inconsequential, though here directly we may treat the severity of the task differently if we know which install is filing it. I think assignee is reasonable to highlight, but is not always present. So then do we only show if it's assigned, or have some pointless placeholder text taking up space. We tend to never hide information, so then on this install we'd be stuck with 98% of tasks saying unassigned. It's all kind of lose-lose which is why it's how it is today (which still feels correct for most installs).

Maybe we should just improve curtain first

Actions are always at the top of the sidebar, and pushing them down inst something I want to explore, since it makes day to day use significantly harder, but maybe it wouldn't be as bad as I imagine.

Personally I'm not really sold on the gutter text. It forces everything else down for what could just be positioned at the top of the sidebar?

It's an interesting idea. I'm not super happy about promoting the author as the "important" part of the task / image, but having a nice summary explaining it's full current state seems pretty helpful.

One other possibly-bad idea I had was to show only one of these:

I think it actually aligns in practice (e.g., see Differential).

unintentional for a 2-minute mock. See Differential.

v4 moves "assigned" to gutter, and removes Authored (which is the first transaction).

Dunno this feels more heavyweight to me, personally. Probably because this path signs us up to always show Tokens.

Tokens being its own separate island seems conceptually fine to me, although I tend to agree that subscribe is maybe a little weird to disconnect.

Yeah, should be no problem to do mobile magic if that seems like the most promising way forward.

One thing I think about with these actions (flags, subscribe, tokens) is they are personal actions as opposed to object actions. That is, they are for me specifically, and not really affecting the underlying object. It's one reason I think pulling them out feels ok.

lol :)
I don't really like hiding them, but for limited-height-screens... There's just not enough really good solutions.

Oh, notable community member @avivey also raised a concern about hiding options in a dropdown in T8172#117058. :)

I've historically pushed against hiding actions in a submenu, since I think it's a pretty big negative for usability. I'm not totally opposed to heading in that direction but I personally prefer the space being used for actions over any other content. At least today, some of the actions also communicate stateful information ("Automatically Subscribed" shows your subscription state, "Flag for Later" shows the current flag).

Not thrilled about this:

• Arguably, these actions are more used than the actions that are left above the fold. Maybe they should sit on the first part of the main view, like Diffusion's "View Raw File"?
• What happens when we have a 3rd/4th button-worthy action?

The "pull the whole panel out as a curtain widget" approach might also work better for third-party extensions and Phrequent, which isn't enabled on this install but is technically part of the upstream. Maybe the pathway forward there is "delete Phrequent + no support for extending this", of course.

These would become "Unsubscribe" and "Revoke Token" in the same spot?

Other issues:

Please unassign me from this task (why can't I do it myself?). My patch was rejected.

jx-tooltip is a free spirit :3

D14879 made hovercards smart about these sort of things (But hovercard don't have a little arrow thingy).

I always see it like this (Chrome/Windows); I've dug a little in the algorithm, and I think it's using location relative to the page for the calculation, which is why the first (top-most) tooltip acts differently than all the rest.

Are you always seeing this render in a bad location or is it only sometimes? I regularly see the first rendered hovercard located way off to the left but it's only the first hovercard that tries to render -- and it's usually only the first hovercard after starting up Firefox. I haven't found reproducible steps so I haven't bothered to report it yet, but I wonder if it's related to this. I primarily use (the most recent) Firefox so it may be just browser. Using Cmd/Ctrl+Refresh doesn't cause it to affect again - manually restarting Firefox is also not a surefire way to reproduce.