User Details
- User Since
- May 28 2014, 11:12 AM (553 w, 1 d)
- Availability
- Available
Aug 22 2016
@chad, what is the rationale behind processing the very first line of the git commit message (the title)? I can't find any reason to do so, the first line is always the title. If you just ignored the first line and not performed any extra arc processing, this issue would go away. What am I missing?
Aug 19 2016
Jul 24 2015
We're not familiar with the code base, so we weren't sure whether the diff in the description was enough or there was something more to it. It sounds like it is not, so @lbrabec will try to submit a diff right away.
Feb 25 2015
OK, thanks. If you let me know, I can test the fixes once they are available.
@chad, I have went through all the issues in that Scrollbar column, and I have found only T7209 which seems to be a duplicate of problem 1) as described in my report. But it also might be a bit of something else related to trackpads. Problems 2), 3) and 4) doesn't seem to be covered in any of those issues.
I believe I have reported the same issue in T7363, when using mouse, Firefox 35, GNOME 3.14, Fedora 21. There is a space between the scroll bar and the edge of the window where it does not perform a bar grab, but page down move instead. Easily tested with maximized Firefox and moving the cursor to the very right (last pixel on the screen). Which is something I usually do, I just throw the cursor against the right edge and click.
Feb 24 2015
Can you point me to the duplicates please?
Jan 16 2015
The fix is now a part of the Firefox stable release (Firefox 35). The problem seems to be gone.
Sep 24 2014
This has just been fixed in Firefox master branch. It will take some time until it's part of the stable release.
Aug 22 2014
Thanks, we'll try it.
If needed, I'll hang around in #phabricator during central European working hours.
May 30 2014
As a side remark, it would be great if the revision author could reset the "Accepted" status manually, if needed.
As a side remark, it would be great if the revision author could reset the "Accepted" status manually, if needed. That would make sure that the ticket appears in reviewers' ticket queues again. Just saying it in the comment is not that much helpful and can be easily overlooked.
Oh, OK. I forgot to check the FAQ and assumed it was a bug. You're right, this is what this ticket is about. Closing as not-a-bug, Thanks for the link.
Correction, there seems to be no Commented on a prior diff (it just displays a note next to prior diff's inline comments). But that doesn't affect this issue much.
May 28 2014
The more avatar icons are displayed, the higher the CPU utilization seems to be (zooming out the page helps with that). I tried to use a completely fresh Firefox profile, single tab, and profile the javascript for several minutes, but its sampling method reveals nothing:
Please feel free to ping me on freenode (kparal on #fedora-qa), if you need some real-time response. Thanks!
Great, it's happening here as well. For this very ticket, I see 20% CPU utilization as long as my avatar icons are visible simultaneously (the top bar, and the one next to "kparal created this task"). Once I scroll down a bit, the CPU utilization goes to nearly zero.