The form still does nothing useful, but it's not a default any more

Fixed by D17188.

I was able to reproduce this locally -- or something close enough, at least -- by recreating the simpler graph in T12114#207542, so I have enough to move forward.

I'm only trying to help you improve your own software - I have no personal interest in this issue being fixed. Imposing barriers on people taking a brief moment out of their day to draw your attention to bugs in your software seems counterproductive. If you choose not to accept reports of bugs that are backed up by a screenshot clearly showing the issue, then that is your loss.

For the records, Version info for that downstream instance says:
phabricator ef44831309df7b8d4b75ab653d1cd22813147c85 (Dec 16 2016)
arcanist 9c8774f9d30b921f0e4a5a10b98a7820517789a6 (Nov 10 2016)
phutil 77ace948f90c1003c2917175eb0a93c158023bdc (Nov 15 2016)

Finding version information seems non-trivial if you're not an administrator of the Phabricator installation. We appear to be running 0426ce73f0e63f1900f1cc285cfa1465ea72317e.

Please read and follow Contributing Bug Reports. This isn't a valid bug report and won't currently be accepted as is. Specifically we require version information of the install and steps we can follow locally to reproduce the issue.

Starting arc diff and then making changes probably races, although I think that's likely pre-existing. I can look at it when arc gets another update, but I think we can't really fix it on the server side.

D17209 reverted on me twice if you look at the transaction logs. I can try again. Basically I'd start arc diff, which takes 1-2 minutes on my server, go edit the form, then arc diff would actually land, the changes would be reverted. Maybe it's that I started arc diff then made changes?

Actually I can't reproduce this? I did this:

I can't reproduce this. Here's what I tried:

ah yep that seemed to work. I was still specifying releaseNotes for the field which I'm guessing is why it wasn't getting saved. Thanks again for all the help! If you're ever in Pittsburgh I think I owe you about 50 beers at this point.

There was previously a shouldOverwriteWhenBlahBlah() method that probably didn't get transitioned forward cleanly.

• I changed CIReleaseNotesDifferentialCustomField->shouldAppearInApplicationTransactions() to return true to make the web edit to work correctly. (Did you not want this field to be editable from the web?)
• I changed CIReleaseNotesDifferentialCommitMessageCustomField::FIELDKEY to integrator:release-notes (the same value as CIReleaseNotesDifferentialCustomField::KEY_RELEASE_NOTES). Although this is not strictly required, it needs to be the same in some cases to bind the CommitMessage field to the Custom field, and making them the same makes several behaviors work correctly without additional changes.
• I implemented CIReleaseNotesDifferentialCustomField->shouldAppearInConduitTransactions() to return true;.
• I implemented CIReleaseNotesDifferentialCustomField->newConduitEditParameterType() to return new ConduitStringParameterType();.

Alright, I'll take a more detailed look.

I pulled in that change and I'm still seeing the same issue. Editing the field from /differential/revision/edit/... seems to work normally, but adding it via the differential.createrevision endpoint does not.

@jcox, do you have 62cf4e6b95abbebc8ae2b1591039967651188c6e (D17207) yet? That might be the fix. Nothing jumps out at me as wrong, but I can take a closer look if that change doesn't help.

Please follow the guidelines in Contributing Bug Reports. Specifically this ticket is missing reproduction steps we can follow locally to see the bug, and version information. We don't accept incomplete bug reports. Thanks!

Are you able to reproduce the bug on a test instance on Phacility? We need to be able to locally reproduce a bug to accept it.

Checking in for guidance in case this is the wrong way to go. I have a custom field which extends DifferentialStoredCustomField and I'm trying to convert it in the same way as the above. Thus far my field isn't being saved when calling differential.createrevision. I've included the DifferentialCommitMessageCustomField and the DifferentialStoredCustomField below.

Additional info - Phab is updated to Master stream after appearance of problem.

Assuming "git extensions" is https://gitextensions.github.io/ - this is rather outside of the scope of support you can get here. I suggest you contact them to figure out how to get the PATH to be properly populated (git isn't in your path).

See Contributing Bug Reports and Providing Reproduction Steps for more information on what's required in a bug report.

This isn't a valid bug report. Specifically we require version information and complete reproduction steps. Using a new, clean instance on Phacility, I am not able to reproduce the bug you state.

Yes, the rest of the tag is good. I just don't want pinch-to-zoom to be disabled.

Oh, sorry, you just wanted maximum-scale removed.

Here are some screenshots of Phabricator with this tag removed, as you suggest:

I'm not asking you to implement a new accessibility feature, I'm asking you to stop *preventing* an accessibility feature from being used. Browsers already do this; you just need to stop telling them not to.

As you might already have guessed, this isn't a bug.

I'm just going to merge this into T9640, it isn't meaningfully different from an implementation perspective and is the major compatibility issue.

I haven't explain correctly, what I mean is that this task is "Needs Triage" now but you can know how many work you will need to do (more or less) then you can set its priority (low, hight, whatever).

Ah, cool. I'll throw something hacky over this for now if I have a chance, then.

I started redesigning the main header last night, don't expect it to land before stable cut this week. I'll probably land it all at once. (Header Redesign + Favorities Menu).

I think the item didn't exist at all before, and T11114 created it as a side effect. All the installs I have immediate access to are up to date, but, e.g., neither the KDE nor WMF installs have "Create Diff" or "Create Revision" in the menu even though I have access to Differential on both.

I can't think of a reason to prioritize this. Specifically, it seems like since Phabricator for most (all?) companies is a business critical piece of software, you'd always choose to run it on the most reliable / stable version of PHP. Is there a reason we should consider that not to be the case?

Now that PHP 7.1 is released you could think what will need to be changed and give a priority to this task.

For what it's worth, we tried disabling the sprint-plugin but we still get the same result.

Before the menu item seem to be called Create Diff and it worked. Right now it's called Create Revision and clicking on it shows an error:

Actually, I think this is a separate bug, moving to MenuItem, it's still broken there as well. Probably related to T11114

I believe D17183 fixes this. If you're still seeing issues after upgrading past that change, file a new issue with modern reproduction instructions.

Great, thanks for the report! This should now be fixed in HEAD of master, and promote to stable within about 72 hours.

I tested the patch on my install and it restores the old behaviour!

Unfortunately i'm not quite sure from exactly which version we've upgraded from. But you're probably right and it was a version before Aug 17.
I regularly read the release logs and in the ones i checked before upgrading (which was about 2-3 months worth of em) the latest Modernisation seemed the only thing touching something related to the problem.
D16413 probably didn't make it into any changelog or was just such a minor note that i didn't see it.

I believe this behavior accidentally changed in D16413, on Aug 17 2016. That change caused us to use the commit's project tags instead of the repository's project tags.

Awesome! Sorry for the churn here -- I think we have a brighter future on the other side, but have to break a few eggs to get there.

This does not describe a bug in Phabricator. See Support Resources for help understanding available support resourecs.

Thanks that did it! Still working through an issue with one of our more *ahem* exotic applications, but I suspect that'll be a more involved refactor on our end.

This doesn't reproduce for me and we don't support third-party code, but it's entangled with T11114 and can stick around until I get rid of the old table.

We've formally frozen this method after D17158. The UI now encourages project.edit.

Can't reproduce this - assuming fixed?