At HEAD of master:

This is "fixed" by the associated series of diffs, in the sense that the actual problem (being unable to delete web UI config) is fixed. This is remaining work:

@chad yes it is but I don’t want to disable it everywhere. It’s quite useful. Most websites just disable it selectively in places like search bars. I would also recommend disabling on form input like settings. Especially anywhere where phabricator autocompletes to some object like a project/user for access control etc. I hit this a lot while modifying many repositories visibility policies.

See T12874. Your account will be disabled if you continue creating tasks like this. Follow the instructions you were given.

See Support Resources

You can find tasks with no owner by searching for "No Owner", like this:

This is something that is needed every day, e.g. find tickets which are not yet assigned..

/config/edit/translation.override/ then add the string, and what you want it to say instead. That's the quickest path here. Merging into the other request.

Can you be more specific here? If you just want to rename "LDAP Login" you can already do that with the translation framework.

I believe that's a Safari feature that you can disable?

They already --prune when pulling:

We've run into this same problem, but in the phabricator daemons. They also, apparently, run commands like:

git branch --verbose --no-abbrev --contains <sha> --

For private reasons affecting the reporting install, this no longer has customer impact.

OOOFFFAAHHH

This might not be totally related but

1. I really love being able to see the filename while scrolling through files
2. It would be useful to have something similar to Diffusion's File Search on a Differential revision, to quickly jump to files based on name. The f sidebar helps a little but it's organized in a file-system layout which means the folder location needs to be known.

That sounds like a bug, but my guess is that the investigation would probably turn up "wow you are dumb at writing software" in about 3 minutes and not really get us much closer to a fix, which is probably "rewrite arc patch to fix 200 problems".

For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.

Also, I've noticed that when applying dependent revisions like this, it seems that usually all of the commits will apply cleanly (without prompting) except for the last one, which will always fail to locate the commit to apply on and prompt whether to apply to current working copy state. Based on what I think arcanist is doing I would expect all patches to prompt whether to apply to working copy (since all patches will be given new commit IDs) -- it seems strange that all will apply cleanly except the last one. Does that sound like a bug or am I misunderstanding what's happening? I can try to investigate/debug if you think it might be a bug.

For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.

D18152 should improve this: we'll still select the item as the default item, but will now render the navigation normally so the user can click other items:

Specifically, the issue is that multiple different priorities used the same keywords ("low", "high").

Sorry, I should have led with a screenshot! I'm the biggest nitpicker, I know.

This looks like the update changed the behaviour, not sure if this is intended, but it broke configs, that worked before. I currently fixed this by chaning my config to:

{
  "100": {
    "name": "Unbreak Now!",
    "short": "Unbreak!",
    "color": "pink",
    "keywords": [
      "unbreak"
    ]
  },
  "90": {
    "name": "Needs Triage",
    "short": "Triage",
    "color": "violet",
    "keywords": [
      "triage"
    ]
  },
  "80": {
    "name": "High",
    "short": "High",
    "color": "red",
    "keywords": [
      "high"
    ]
  },
  "70": {
    "name": "Higher than normal",
    "short": "Higher than normal",
    "color": "orange",
    "keywords": [
      "high-than-normal"
    ]
  },
  "50": {
    "name": "Normal",
    "short": "Normal",
    "color": "yellow",
    "keywords": [
      "normal"
    ]
  },
  "25": {
    "name": "Lower than normal",
    "short": "Lower than normal",
    "color": "green",
    "keywords": [
      "lower-than-normal"
    ]
  },
  "1": {
    "name": "Low",
    "short": "Low",
    "color": "sky",
    "keywords": [
      "low"
    ]
  },
  "0": {
    "name": "Wishlist",
    "short": "Wishlist",
    "color": "skyblue",
    "keywords": [
      "wishlist"
    ]
  }
}

I think that these use to exist and were moved to a help document somewhere.

I was able to track this down: This is happening since {rP8008ade9af46d417aec187f4213118d220077b32}.

(That is, our behavior seems clearly incorrect.)

This just looks unambiguously wrong to me.

I'm going to modularize this, but not before the release cut.

Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).

I can verify this fixes it! Thanks for this guys.

Thanks, that's much more clear than the original description!

No they're not. I know it's a tiny difference, but look at this closely (left is my proposal, right is the current state):

(I think D18132 should fix this once someone gets a chance to look at it.)

I'm confused here -- the icons are already struck in every browser on my system (Safari, Firefox, Chrome):

This should now be fixed in HEAD of master, and promote to stable within about 12 hours. Thanks for the report! Let us know if you run into anything else.

I’m fine waiting for the fix. Thanks @epriestley

A related issue surfaced recently. Actual use case (forensically reconstructed):

Oh, this is actually the Mercurial flavor of this action. We have this one in the Git flavor, which is why I was surprised:

My expectation is that this action can never appear -- this is the pre-Drydock hacky temporary action -- so something troubling is afoot.

See also T10005 (bulk editors for all applications) and T6722.

I think a minimal reproduction case which is typical of this example is:

Looks to be just the presence of the "?" in the text

"XXX://123456 XXX XXX XXX://123456 XXX XXX"