Hi, I'm not sure how Phabricator handles compatibility libraries but PHP has http_response_code() available which sets the status code and message in one go. The fix for this task could be introduced as a compat method for PHP < 5.4.

A simple way to compare scroll distance is to open multiple browsers, scroll all the way to the top and scroll the mousewheel down one notch. Chrome on Windows puts me halfway through the task's title, while Firefox barely escapes the top bar.

In T7109#94036, @epriestley wrote:

I think the issue is that we're technically scrolling a frame, not the document root.

You are right - if I remove the 'overflow: hidden' and 'overflow-y: scroll' styles scrolling is fast as ever! I cannot find any reason on why Firefox would reduce the scrolling speed for a single frame.

In T7109#94031, @epriestley wrote:

You can keep the natvie scrollbar on screen by commenting out this line:

https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/externals/javelin/lib/Scrollbar.js;37e534c5f8a65978533d43907290b04c3f3b6e0e$302

You can disable the non-native scrollbar completely by adding return; here:

https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/externals/javelin/lib/Scrollbar.js;37e534c5f8a65978533d43907290b04c3f3b6e0e$29

In T7109#94027, @epriestley wrote:

@GMTA, do you have an older machine or a netbook or something like that?

I'm seeing a huge difference in scroll speed between Phabricator and other sites, and I'm 99% sure that scrolling is slower since the introduction of the new scrollbar. Is there a way for me to temporarily use native scrolling (through the console?) to confirm this?

Vertical scrolling seems about 3x faster using the native scrollbar in Firefox based on visual guesstimations.

And on an unrelated note: personally I don't think T7014 was worth replacing the native scrollbar with a fake one throughout Phabricator. There have been exactly zero convincing, bug-free, user friendly fake scrollbars on the internet up until now, why is this one going to be different? :)

This is also an issue on Firefox/Windows.

This issue is also present in Firefox.

I've done a bit of research on exactly these two MySQL errors in order to create a deadlock-proof subsystem for an application of ours. In my experience, the causes you attribute to these two errors are the wrong way around:

I could name another reason: interoperability between Firefox and Flash on Windows has been abismal the past couple of years, crashing or hanging plugin-container.exe causing a lot of us to preemptively disable the Flash plugin. Using web sockets (where available) would be a great improvement.

If I resize the window to small enough dimensions to make the sidebar disappear, the icon stops jumping.

In T6457#82044, @epriestley wrote:

Does this reproduce across multiple browsers? I can't reproduce it.

No, it does not. I've created a gif animation based on screenshots which truthfully represents the vibrating effect we see in Firefox (I've blacked out the other people):

In T6457#82035, @epriestley wrote:

We allow profile images to contain animated GIFs. Is it possible this is a specific user who has uploaded an animated icon?

No, these are PNGs. It is not always the same user icon that moves, and the same user icon is not always moving.

Maybe this pattern could help: this particular wiki document was moved ("This document was moved from elsewhere"). The second error I get on reindexing also refers to a wiki document that was moved.

In T6406#81315, @epriestley wrote:

• Running bin/remove destroy <phid> is usually a reasonable way to resolve the error. Ignoring it is also reasonable.

I've tried that just now:

tools@dev1:~/phabricator/phabricator/bin$ ./remove destroy PHID-WIKI-amenci5bzyxy5k4ndwwu
Usage Exception: No such object "PHID-WIKI-amenci5bzyxy5k4ndwwu" exists!

So I did a text search through all databases and found relations to this PHID in the following tables:

• feed_storydata
• feed_storyreference
• phriction_document
• search_document
• search_documentfield
• search_documentrelationship
• worker_taskdata

Maybe this could help in finding the source of the bug. Thanks for the explanation, I'll just ignore it for now!

In T6406#81303, @btrahan wrote:

Huh, I didn't know that was possible. How does one check the definitive shell history of all users on a given host?

We have single user access for our central phabricator install, whose sessions are explicitly logged in case of stuff like this :)

Thanks. I've just checked our shell history; no bin/remove was executed.

I never said that that PHID is valid... Obviously it cannot be found. Somewhere, somehow, a stale reference seems to be left behind. I cannot find any documentation about how to fix an issue like this so that's why I think there's a bug somewhere in the wiki application?

Are we at an impasse here? How can I contribute to this task?

Wouldn't D10323 and rPfca8b5ab1b36 have fixed this issue?

I just tested your diff on our installation and it works perfectly. Thanks!

I was searching on the 6 leading characters of the ID... I was expecting a search on commit ID would work more like other applications. Thank you!

Did you just tell me how to raise my dashboards? You did not just tell me how to raise my dashboards! You do realize that you're replying on a serious software issue, right?

This bugs seems to appear throughout Phabricator, not only Phriction.

Found it: if I click on the "X", it never works. If I click in the box just next to the "X", it works every time.

I'm using Firefox 28 on Windows 2012 server. I just noticed that sometimes, the first time I click I get a dialog asking me whether I want to unpin the application. If I cancel and click again, it fails. Other times, it just fails without notice.

In T5188#6, @chad wrote:

This is what I am doing to attempt reproduce, please correct me if I am wrong:

• Go to any comment field on Phabricator, for example new task.
• Drag a .jpg file from the Desktop into the comment area.

In T5188#3, @chad wrote:

can you give a more specific set of steps to reproduce

Drag a file from somewhere (desktop or whatever) to the Phabricator dashboard. Phabricator should show you a message about uploading files. Before releasing your mouse button, press ESC to lock the interface.

In T5028#19, @epriestley wrote:

However, I assume you'd still want this even if the %B issue was fixed, @GMTA (that is, you have other problematic commit messages which you'd prefer to preserve linebreaks on, and which are bad for reasons other than improper list formatting)?

Looking back in our git history, I think the problem is most prevalent with lists in commit messages without that extra newline at the beginning. Most of the other messages follow the git commit message "best practices" so they have a summary line at the beginning, followed by two newlines. If we keep to those guidelines, this issue is resolved for us.

I think it has something to do with the double breaks being parsed while single breaks are ignored. Two views of the same commit in git and Diffusion:

In T5034#9, @epriestley wrote:

T4980 will likely let you do this yourself, depending on how it pans out.

My personal opinion is that manual text wrapping in any system because of an arbitrary character limit is just plain awful, but a lot of git users seem to apply it. I think a sane default should be text-mode remarkup (suggestion 1). If users would like to automatically unwrap manually wrapped texts, wouldn't that be served best with a non-default option?