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.

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

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

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

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.

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

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

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

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

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

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"

You and me both. I am super confused.

Well the stack trace says PhabricatorYoutubeRemarkupRule, so I'm confused what the issue is.

LOL @chad Literally reproduced this issue here by trying to paste the above line without the back ticks. It refuses to let me comment.

I'm not sure how without giving you the entire commit message which I cannot. I think key would be a having a commit with a line (probably the first one) that looks like this "XXX://123456 XXX XXX XXX? XXX://123456 XXX XXX XXX"

How can we reproduce this issue locally?

There also seems like there may be an issue with the current parsing logic since the "detected URI" has spaces which I do not think are valid in a uri and it should have been detected as two separate URI's with some stuff in the middle.

The URI that is ambiguous is a URI to a company App on MacOS. The only part of the URI that matters is the xxx://123456. The rest is just the title of the item referenced by this URI and this title contains a "?" which mixed with T12526 may be causing this issue. There may also be a place you now need to catch exceptions thanks to URI parsing logic changes. Just guessing here from what I can tell in the code.

Why is git diff --no-index being used instead of and diff, and why is --no-prefix being used?

@epriestley git diff --no-index --no-prefix -U2000 $old_file_path $new_file_path

I'm not really sold on this use case, but I think the result is unintuitive/buggy enough to fix anyway.

Unicode Zero Width Space to the rescue!

Ahhh, that makes more sense. I parsed that as saying "we could migrate the code" instead of the saved objects. If you want to add the glue code now and then assign it back to me after, I'll work on the migration in my Copious Free Time™.

Oh, sorry, maybe I wasn't clear. My plan is this:

If you're happy long-term with accepting all three types, I'm ok with that as a permanent fix. I'm planning on working through this week, just with weird/inconsistent hours.

Yes, we could migrate these instead.

Are saved queries/EditEngine forms things we could write migrations for? That might be even more brittle (for example, what to do about saved queries for priorities that no longer exist on the install), but accepting three different priority specifications of two different types seems a little too Postel's Principle for me.

I think this is a general problem with all JSON config types. The code for this is a bit messy and mixes "builtin" and "custom" types, but should probably just be rebuilt to not have all that weird magic.

This came from D18028, when I changed the Include stories about projects I am a member of. checkbox to be a CheckboxesField. I think the issue is that existing saved queries may have the old value for the field stored (true), instead of the new value (array('self')). These queries would be impossible to construct in the UI now.

I'll see if I can smooth this over a little before installs figure it out.

After some additional poking, there are a couple of other compatibility issues here:

It was restricted as a prototype for testing, I don't believe there was an originating task, maybe T8250. If you liked it, let us know!

Please remember to update Phabricator before filing bug reports. This UI no longer exists.

My guess though is the Mac your using is a laptop without a mouse. We didn't display the bar on "touch" interfaces, which MacOS + Trackpad registers as.

Please remember to update Phabricator before filing bug reports. This UI no longer exists.

I didn't see this bug report earlier and was about to...start sprinkling error_log() everywhere to see what was going wrong. (What better way to spend Friday afternoon, right?)

What is the problem? What is wrong/not working?

I'm not sure I understand something:

I am running into this issue too and am on commits: