Ah, then it will be some of our local enhancements... Sorry for bothering then.

next batch is ready, should land tonight:

In the future, we might reasonably want to put tabindex="1" on the first input on form pages, like the "Edit Task" page, so that you could press tab once to quickly begin editing. If we put tabindex="1" on global search, the cost of making this change in the future will be much higher.

Phabricator has no such sidebar item. Where are you seeing this?

Good point, thanks for research. I was looking in some notes from research done several years ago, thus obviously no longer accurate.

Can you substantiate "f" being "typically used"? Here's what I see in use in the wild from a quick survey of popular sites and software:

Those are all about preferences and JavaScript handling...

This feature has a tiny impact and a huge support cost.

I can look in more detail when I'm back home. Kids have a picnic today.

That's what I plan. Just tested it on WXPx86 and FF 47.0.1 32bit and it works there.

The next step on this report would be for you to try to reproduce on a different environment.

And FF? And 32 or 64 bit?

Tested 8 and 10. I don't have Win7.

@chad Which version of Win & FF you use?

I don't see anything relevant there actually, could you please elaborate?

I can't reproduce on Windows, Chrome, FF, IE with en layouts.

See discussion in D15984.

Tested in both en and cs layouts.

/ was removed, see D15976 and the changelog:

Same problem :
Versions :
phabricator bc3ac3158448dfe966d05787fa9272f08ddc7faa (Fri, Jul 1)
arcanist 4d4d16f25985f133501f20fdddd183e525f00341 (Wed, Jun 29)
phutil dde2f74f2793f0216f0d76618ed335a9c802cfec (Fri, Jul 1)

In T11105#179265, @hach-que wrote:

This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).

We probably need to do almost all of this work before adding new panel types anyway, since building a new panel type on top of CustomFields would make moving everything from CustomFields to EditEngine harder.

In T9360#183602, @chad wrote:

Is [HTTPS] simple? Not sure where to start? Nothing is jumping out at me here.

Suggestion from one chat I had:

I mean even having just a "Revert" button for each change would be easier
Even if you had 50 to click, it's better than manually undoing :)

FWIW we'd be perfectly fine with the following:

• allow editing phriction documents via Conduit
• create a panel which shows the contents of a specific phriction page

In T9360#182482, @epriestley wrote:

Oh, and we select the correct protocol for custom domains now, but don't enforce it when serving content. That is, these both work, and we always link to "https", but "http" should redirect you directly to "https" instead of serving content:

• http://blog.phacility.com/
• https://blog.phacility.com/

The actual panel transactions that we need to update for this aren't too bad. The board transactions are a little more involved, but we can skip them.

This could still be improved, but the immediate confusion we encountered appears fixed.

We can fix the highly-tractable web UI part, at least.

(Just bookkeeping; there's no external priority on this.)

I'm moving this to "Rugged Terrain", as the best available pathway forward leaves us with dramatically higher implementation cost than the reasonable value of the feature. We can pursue this after tasks with better aligned costs and value are addressed.

Mooted from a prioritization standpoint by D16139.

but yeah, a spacer could help too

That sounds good to me, should give us more clarity around the dashboard stuff.

Maybe I should just design out my dock idea, the dock then goes with Dashboards (admins can set the apps, etc).

When you're editing a homepage dashboard, just having a spacer bar there for the applications menu might help make it more clear that 66/33 is better in a lot of cases than 50/50 -- currently, you can't see what stuff will really look like until you're already done and installed.

I think some sort of logged out / open source public template would head off like the majority of these. I think I had a plan in another thread.

wow pretty sure I even picked numbers that add up to 100%

I definitely think we should skip the 3-column versions for now, I don't think we've seen any kind of need for them in practice. We could look at it again after Facts since I think some of these weirder things could make more sense on standalone dashboards, the app just isn't powerful enough yet for that to be paritcularly useful.

this guy is clueless: T5531#66370

T6444#81725

The other solution is just to make it so these are more hidden / advanced options. That the defaults we provide are good enough that users just modify those templates instead of making one from scratch.

Do you think 50/50 and 33/66 are always bad even for standalone (not-on-homepage) dashboards? e.g., if we had a "Phacility Metrics" dashboard in the future after Facts, a 50/50 of a "Users" column and "Revenue" column or whatever could never be a useful way to present the information?

My rough thinking for new homepage is roughly consisting of three things:

Haha, that's probably T10612.

Babel seems to have the same panel in both columns, too.

The problem with 50/50 layouts is they don't guide the user anywhere as to what is important. It basically says, everything is important and conversely, is difficult to follow the page since panels just appear everywhere.

Why do you think installs (offhand: Babel, WMF) are picking 1/2 + 1/2 if they're strictly worse than 2/3 + 1/3?

You're the only user we're currently aware of who wants to use the software like this, so I don't plan to address this use case at this time.

In T11260#183515, @epriestley wrote:

But when I am looking at my calendar app, I want to see local times, for whatever timezone I am in.

What would you like Phabricator to do when you look at events in its Calendar application?

But when I am looking at my calendar app, I want to see local times, for whatever timezone I am in.

Got it. Thank you! I just started the reindexing operations recommended in this release so I may leave things be 'til that finishes.

they won't not exist

"Ignored" in the sense of: no publishing, no herald rules, no audit triggers. Not, like, "they won't not exist".

Only that any legitimate commits pushed until things catch up will also be ignored. The repository will automatically leave the mode once everything finishes.

Ok; will let it do its thing then.

There was a relatively recent change to make Phabricator discover commits which are only reachable from tags and refs. As it discovers these commits, it will treat them like new commits and publish feed stories about them. This is a one-time event, but a few installs have a lot of tag-reachable commits for whatever reason. You can find a bit more discussion in T11188, and details about the change in T9028 and T6878.

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

Ah, I found the problem in our upgrade script. We run our upgrade in the following order:

Thanks for quick response; hadn't seen this before so couldn't tell how serious the errors were.

Oh, or Apache.

Just rebooted apache once more and things are looking better.

Also likely fixed by restarting PHP-FPM, that method is defined here:

Did you restart everything after upgrading? See Restarting Phabricator.

Getting the following when I visit differential/:

From the Firefox bug and this linked one:

This appears to be stable, and is now accounted for.

This seem quiet and is now accounted for.

This appears functional and is now accounted for.