Before we didn't render the table, so the link to visit said table as full screen, doesn't exist. I think I need... better fallback here.

The reason I took navigation away is we throw exceptions instead of error messages when master isn't present (or have no commits yet). Do you remember the reasoning there (using Exception)?

ok thanks for the nice and easy repo steps. I'll have something after lunch, got appt at 11

I believe the issue here is:

oic k thx

In the refcursor table, our current autoincrement is at 312,036,016. This is only 7% of the way to int unsigned, but the fact that we've made it to 7% in 18 months might suggest that column should be BIGINT, unless there are performance impacts of that.

it might have something to do with appearance.

All my firefox tests, as expected, look like 💩 😦

The expected case doesn't reproduce for me

I think (?) this reproduces for me, too:

It seems like a bug in FF to me

Hmm I've tried on two separate OSX machines using Firefox and can reproduce

I still can't reproduce it locally. Tried colors, tried high-contrast.

kk

At least, change from 464C5C to 000 when using Default Mode (not High Contrast), caused the menu to appear in the same fashion as High Contrast

It's the color of <select>

I don't know, I mean, I'd like to understand what triggers it to look so much better, but it's not a regression it sounds.

So this may be invalid? @cspeck just had to turn on High-Contrast on the test install~

Disregard the different installs - I can reproduce on this install as well just by switching High-Contrast on/off.

The difference appears when using High-Contrast vs. Regular-Type

Errr I may need to investigate further - this install has the same "Mid-April" style using this same browser. I noticed this change on our test instance after upgrading to the latest. We don't inject any styles/js or anything so I'm not sure why that instance would be different.

If we think it's a CSS change, and not a FF issue, going to have to bisect for it. No matter what I do, I can't get that menu to look like that on Firefox.

Not particularly - I copied the select HTML into a "Tryit Editor" from W3:
https://www.w3schools.com/code/tryit.asp?filename=FHPUWOW4JNFN

FWIW, ours looks the same as every dropdown I can find on other websites using Firefox 54, Mac. Do you have an example site that looks like your "Mid-April" install.

See PHI11. This has material impact when using PhabricatorRepositoryRefCursorQuery to query landing targets, and likely impacts the logic in DifferentialRevisionOperationController.

I can't prove it but it feels like the new style is a bit sensitive to selecting an item -- sometimes when opening the dropdown menu the first item auto-selects and closes immediately. I can't prove it though.

Thanks @pooyajavan for your update. But in your solution, the Blueprint is cloning the repository, which I don't want to do that just for running a simple cmd.

Hi I have found the solution, added in stackoverflow, forgot to post it here again.

I have exactly the same problem. Any update regarding this issue?

My install hit this today: we're trying to upgrade from http -> https, but don't want to break users with the old http:// address in their .arcconfig (either because they haven't pulled master recently, are working on a different branch, are bisecting to a commit prior to the .arcconfig being updated, etc).

I think we end up more consistent overall if "Resign" and "Accept" have the same behavior in this case.

That sounds less surprising to me, in the sense that it's not an explicit reversal of having requested changes. I can imagine arguments in both directions for the resign case.

From reading the code, resigning (instead of accepting) probably also leaves the revision in "Needs Revision".

I've seen complaints about this on phabricator.wikimedia.org as well, so I can confirm that this is an issue.

O.O

Also, have you tried looking around the git community? I was always under the impression that SSH should be faster than HTTPS cloning, or possibly using the same protocol.

Solves things for my instances, cheers!

Going to keep this Open and build out some proper blank states. This feel pretty janky.

I pushed a hotfix up at HEAD of master, let us know if you're still having problems. Thanks for the report!

Please provide reproduction instructions. There aren't enough details here.

Hm, this screenshot made me dig a bit into the whole thing, so here is what I've found:
First, my date format is different because of my settings:

• Default settings of this instance: F5042482, with date format: F5042480
• My default settings: F5042481 with my date format: F5042479

Why does your date format look different than ours? Is that a local modification or do we support this somewhere I'm not aware of.

Merging over so there is one thread on this topic. We're happy to reopen if you have new reproduction steps we can follow or if you can verify on a Phacility test instance.

I can't reproduce this (again)

Here's the proof: F5042439

FWIW, I don't think these are "pure" spam emails, as in, that they are 100% unwanted by everyone. Even if you cannot see the underlying diff, you've asked to be notified when work happens essentially on a task. I think it's difficult to have Phabricator assess whether this email is informative or not to each individual user who subscribed. To some who are waiting for the product, it's valuable, to you or others perhaps not at all. Client side filtering still seems like the correct workaround until T5791 (which is server side email filtering).

Hmm, what did you try for search, off hand, do you recall?

In T10745#229028, @chad wrote:

I'm not sure I follow what you're trying to tell us.

I'm not sure I follow what you're trying to tell us.

These types of e-mails are still being sent. Here's one from July 10, 2017:

👍🏻

Ah sorry, I should've made that clear. Yes, I am able to reproduce the issue on our installation.

Were you reproducing a local issue? That wasn't my impression, unless I'm misreading it. It seemed specific to secure.

In T12907#228951, @chad wrote:

This is not a test install.

This is not a test install.

Awesome.. Thanks!

I pushed this to HEAD of master, we'll cherry-pick it shortly to stable.

This is fixed in D18189.

I don't have any great thoughts here. I'd dig into MySQL and see what limits might be getting reached that it's turning away connections. I presume you did not set up clustering in the database? Unclear what "I even only have one master an replicas." means.

I can supply more information, if Iknow what is necessary. But let me try to clarify the issue.

To take a step back, the upstream has exceedingly limited "free support" resources. So in exchange for providing free support, we simply as users to read and follow guidelines before submission. This reduces support overhead on the upstream and means more time can be spent both providing support to other users or by developing new features. There are more detailed discussions on how we can continue "free support" and "paid support" under T9212 and T12681.

And wow on your reply. Just ... wow.

The document I linked (and also on the form you filled out for reporting a bug) state the requirements on what's required for a bug report. I marked this as invalid and directed you to a document on how to resolve it.

@chad It's more helpful. If you would have a template instead of a page long instruction.
+ If you tag it as invalid, it's also nice why it is invalid. I provided versions and logs.
+ if you leave user alone with her/his problems, they lose wish to use it.

Please read and follow Contributing Bug Reports.

I get the same error after delete project by "bin/remove destory phid". I find that the phid has been removed from edge table in mysql but the phid exist in project table. so I delete the phid project record in project table just resovle it

That use case doesn't strike me as compelling enough to justify a separate field or a behavioral change so I don't plan to adjust our behavior here.

In T12900#228746, @epriestley wrote:

Only you and users who have permission to edit <Blog Name> can see this draft until it is published. Use "Publish" to publish this post.

...would that resolve things in your case? Or does the rule we actually implement not work as well as "only the author" in your use case?