Page MenuHomePhabricator

Open bugs through User/Project page goes to broken URL
Closed, DeclinedPublic


So I'm being hit with a few strange bugs when I try to go through a project/user to find their tasks. It appears a set of brackets () is being added to my URLs after immediately after the status parameter. Removing these brackets loads the expected page. With these parameters, you see your assigned bugs. Attached screenshots to try and illustrate the problem.

Is this a known issue? Can anyone reproduce this problem?

Event Timeline

lcawte created this task.Jun 1 2015, 7:34 PM
lcawte raised the priority of this task from to Needs Triage.
lcawte updated the task description. (Show Details)
lcawte added a subscriber: lcawte.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 1 2015, 7:34 PM
Aklapper triaged this task as High priority.Jun 2 2015, 12:33 PM

Thanks for reporting this. Confirming in Firefox 38.

  1. Go to (others users like qgil also work)
  2. See link goal of "Open tasks" in sidebar:
  3. Click it
  4. End up on a page with a list of your own assigned tasks, instead of lcawte's.
  5. Reload that page and see the expected results displayed.
  • Accessing the URL in #2 directly works as expected for me.
  • Cannot reproduce the problem on (but they run git master). Difference: Upstream query parameters show "Statuses: Open; Stalled" instead of our "Statuses: Any Open Status" for the list of assigned tasks.
  • Could not find any upstream ticket; closest is a closed one from a year ago in

Tested this on Ubuntu 14.04 in Chromium 41 and Firefox 38 and could not reproduce.

The () do show up in the URL, but the tasks are the right ones.

Qgil added a subscriber: Qgil.Jun 2 2015, 12:48 PM

All looks good to me, trying with two usernames and two browsers, both from @lcawte's open tasks and my own. Hm.

I still run into this on Phabricator user pages with Firefox 38 and am still puzzled.

Further notes:

"Back" behavior: After 1. going to user page, 2. clicking "open tasks" and getting my tasks instead, 3. reloading the page and suddenly getting correct results:
Pressing the "Back" button makes Firefox display in the location bar but the window still displays the previous view (list of tasks) instead.

Request Headers: When clicking the "Open tasks" link on a user page, I get three additional lines, compared to accessing the same URL directly:

X-Phabricator-Csrf: B@5c33ief6e625a89012345678
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 63

In upstream, I don't see those request headers printed (does not mean much though).

POST request type: In WM Phab, the 200 POST request (triggered when clicking the "Open Tasks" link is listed as Type "plain". But when reloading, the 200 POST request is Type "html".

In upstream, I immediately get Type "html" and the correct list of tasks.

Strange - it seems this does not happen with Firefox 39. So some client side code is hooking in to the click on that link somehow? Odd.

Aklapper closed this task as Declined.Jun 11 2015, 5:22 PM
Aklapper claimed this task.

User-side issue, closing as declined. I'm sorry for the noise.

Must have to do with Firefox profile data (though I had already "restarted Firefox with add-ons and extensions disabled" when I tested).
Tried on another machine after completely nuking ~/.mozilla/* there and behavior was as expected. Now after hitting the "Refresh Firefox and reset all settings" button it also works on my main machine.

I think there might be a race condition in the javascript event handlers on the page, and some combination of browser settings / extensions triggers the weird edge case which causes javascript to hook an event it shouldn't be hooking. (I did some step-debugging through the page javascript / event handlers and it looked like that was the only possible cause )