We probably would not use an option to turn the feature off (versus just supporting it) so don't worry about adding it on our behalf. At the point where I was set up to convincingly test that turning the feature off worked -- and we had navigated bundle2 in some way -- I'd probably be most of the way toward proper support anyway.

Heads up: Mercurial 4.1 (to be released ~February 1) introduces media type negotiation in the HTTP protocol. https://www.mercurial-scm.org/repo/hg/rev/753b9d43ca81 captures the wire protocol changes and the commit message explains why things are done the way they are.

It also occurs to me that Project profile menus already show up in a main menu dropdown on mobile, so we must have some PhabricatorActionView::newActionViewFromItemView(...) sort of code in there somewhere.

Sweet.

Awesome. Things appear to be working now. I suppose I can strip out all the overrides that the most recent commit stripped out. Sweetness.

Yes, if you aren't in edit mode. Here's normal mode (includes field):

so if isFieldEditable and isTemplateField are both false, will the field still show up in getcommitmessage?

In particular, your code may just work as-is after updating. If not, compare them with those "MagicFlag" fields and/or let me know what you're still seeing?

Alright, after D17207 I think these are analogous to what you're doing?

please also add "close menu" and a label that says "menu items" and help text that says "click an item to activate it"

Resign Header -> Redesign Lists -> Redesign ProfileMenu

hahaha
ha
h

phuix-js builds phabricator-action-view, so that's what I was planning to be king.

This diff will be a wondrous, wandering tale or action, adventure, mystery, intrigue, and touch lots of random stuff that should have been broken apart.

Yeah, I'm not aware of any real difference between them or good reason to have both. Maybe I'm forgetting something but I'm pretty sure we can merge them eventually.

Yeah I think we shouldn't have two types of lists.

I think there are two approaches:

We are still occasionally running into this problem. A queuing system which ensures some kind of fairness would be really useful for us and others in the situation where demand is much greater than the builder resources. (A similar sentiment to T11153#180635)

One thing I haven't been able to build is the ProfileMenuItemConfigurationQuery -> ActionView

These are now in production. I inched some other automation forward but no major changes.

They are not related. That search uses fulltext indexes (see T11922 / T11741 for recent discussion), not ngram indexes.

I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.

ok, probably tomorrow

uhoh

I plan to land several fires

Solid.

Hour or two if nothing's on fire -- probably today, just later this evening.

Awesome. What do you think the time delta will be between release promotion and the fix you have being merged to master?

@jmeador, I think I have a fix for your use case but it touches enough stuff that I'm going to hold it until after release promotion. Your use case is a bit unusual but should be possible to support.

Thanks. I was modifying php version because when it was last deployed PHP 7 wasn't supported so 5.6 was installed as well so there were two PHP versions on the server.

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.

(I no longer need access to the server.)

Having run the scripts on a new server the only thing I can think of is the fact that the scripts change #!/usr/bin/env php to #!/usr/bin/env php5.6

@aurelijus unfortunately that wasn't it. I had local.json configured.

This was prioritized privately and PHP7 is now supported. Not sure I got everything, but I'm on PHP7 locally now so presumably I'll hit any remaining issues before too long. T12101 is the new informational task. We will now accept bug reports against PHP7. The documentation should regenerate within a day or so. These changes will promote to stable in about 24 hours.

Hopefully Android browsers will hurry up and ignore that tag too..

There are at least some nontrivial effects, like searching for text without "maximum-scale" can imply a zoom:

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.