Try out the new Bitbucket Cloud pull request experience today!

[Tim Creasy]

I haven't tried the new UI yet (I'm on Server).

But I'd like to request that it be possible to do a full-file code review (i.e. enabling a new reviewer to see and comment on all the lines of the files under review, not just diff excerpts with a few lines of surrounding context).

If there's an easy way to set up a complete review like this in the existing BitBucket Server pull request flow (maybe using a new branch/fork/repo?) I'd love to know!

[Alastair Wilkes]

Hi Tim,

Thanks for the feedback! While it is possible to view and comment on every line (including context lines) in Bitbucket Cloud, you can't easily expand the whole file for viewing and commenting -- you have to manually expand context between diff hunks. We're looking at improving that in the future.

On the Bitbucket Server side, there is an open feature request to support comments on context lines here: https://jira.atlassian.com/browse/BSERV-3749

Thanks!

Alastair

[Nick]

If you have a file in a diff collapsed and click that file in the tree I feel like that file should expand in the main view.

[Alastair Wilkes]

Thanks for the feedback, Nick! We're planning to add that improvement.

[Alastair Wilkes]

FYI: this UX improvement has shipped along with some other improvements to expand/collapse behavior. Thanks!

[Alastair Wilkes]

Thank you all for trying out the new UI and for all the feedback! It's very helpful in prioritizing our backlog.

I wanted to provide a quick update on some improvements we've recently made to the new pull request experience:

• We've made lots of changes to improve rendering speed and scrolling performance
• Error handling has been improved
• You can now expand/collapse all files (in the three-dot menu next to each file)
• "Ignore whitespace" is now available (in the three-dot menu next to each file)
• Jira issue keys in pull request titles are now rendered as links
• A very basic activity feed has been added to the sidebar (without links -- see below)
• Lots of bug fixes

Next up:

• Additional performance improvements
• Ability to auto-hide diffs based on a configurable pattern
• Scroll-to-comment from email links and activity feed items

Thanks!

Alastair

[sgautrin]

> A very basic activity feed has been added to the sidebar (without links -- see below)

It seems a bit too basic in how it handles updates adding multiple commits: it seems it only lists the most recent commit in an update instead of listing all added commits or at least the number of commits added.

Indicating if it is force push would be nice as well (I seemed to remember the old activity feed did it, but looking at it the old activity feed did not and has issues with displayed relative time and commits previously added to the PR and later on replaced by others with a force push; maybe I remember incorrectly or it changed since the last time I had used it)

[Alastair Wilkes]

Hi Sébastien,

Thanks for the feedback. We will definitely continue to iterate on the activity feed before rolling out to all customers; what you see now is not the finished version.

That said, adding special support for force pushes is not in scope for this redesign, but we may consider it for the future.

Thanks,

Alastair

[sgautrin]

That said, adding special support for force pushes is not in scope for this redesign, but we may consider it for the future.

That's unfortunate. Force push is an inherent part of a widely used workflow, and there's good support for it in both gitlab and azure devops (don't know about github). Redesigning the PR experience and not using the occasion to at least catch up to the competition is not very wise imho.

[niallmuldoon]

Hi,

Is it possible to increase the 100 file limit? I have a large pull request and can only see part of it.

Thank you!

[Alastair Wilkes]

Hi Niall,

It's not possible right now, but we plan to remove that limit in an upcoming update. Thanks!

Alastair

[Alastair Wilkes]

The 100 file limit has now been lifted.

On a related note, we are aware of some performance issues with large diffs and are working to resolve them.

[niallmuldoon]

Great news! I will have another large PR soon to test with and will post back with any other thoughts.

[Kyrylo Omelchenko]

Hi,

Am I the only one having trouble with syntax highlighting? Does not work for me with python source code.

Thanks!

[Alastair Wilkes]

Hi Kyrylo,

Right now syntax highlighting only works in code blocks in comments and PR descriptions. We haven't added syntax highlighting to the actual diffs yet, but we plan to.

Are you seeing this issue in comments or descriptions?

Alastair

[Kyrylo Omelchenko]

Hi Alastair,

I see. My issue is with the diffs.

Thanks!

[Manish Maharjan]

New version is really annoying when we cannot see whole picture on what files has been changed without any need to jump into the code.

Basically, old view have possibility to view list of committed files in PR, but new one doesn't and also does not show full path if it is too long. 

Also opening a file and browsing a code is too slow when code lines are too long...

[Manish Maharjan]

At least, would have been nice user experience if these features were also ported soon. :) 

[Alastair Wilkes]

Hi Manish,

The file tree in the sidebar is intended to replace the file list from the old experience. Does that not serve the same purpose for you? Let me know!

Also - if filenames are cut off, you can click and drag the edge of the sidebar to expand it, or you can hover over a filename to view a tooltip of the full filename to the side.

Alastair

[Manish Maharjan]

File tree at right hand side is handy to see folder structure and its hierarchy, however lets say that there are 100 files committed then in old PR version it was possible to see list of files that has been changed on top easily. This was giving us possibility to already skim through the list of files and go through files in easy manner. In newer version we do not have that list of files shown on top anymore. Therefore, not the very nice user experience. 

Also, it was not possible to hover over a filename to view full file path or to expand it.

Additionally, if there was a goto top icon when page eventually scrolls would have been very nice. This would reduce time in scrolling all the way to the top if there are 100's of files being expanded in the commit and page size is very large. 

[Jiri Hana]

Not sure if I understand you correctly, but pressing "Home" takes me to the top easily.

[Manish Maharjan]

@Jiri Hana , That's just kind of would have been great feature because there is no "Home" button in Macbook. For the same purpose different key map has been setup.

[Alastair Wilkes]

Hi @Manish Maharjan 

Thanks for your reply! I have a couple of clarifying questions:

Can you elaborate on what makes the old file list more skimmable than the new file tree? Is it the lack of the full file paths? The indentation?

Or is the UX issue that the file tree is in the sidebar and not in the center column? If so, why?

Sorry for the extra questions, but it's really helpful for us to understand the issues! We introduced the file tree in the sidebar to make it easier to navigate between files in the pull request, but we want to make sure it's as useful as the old list too.

FYI - we just added support for more than 100 files in the file tree, so perhaps that helps. And we'll look into adding a "back to top" button. :)

Alastair

[Chris Morse]

@Manish Maharjan On a Mac there are 2 ways to get "Home":

• Fn + left and right arrow keys. Press the Function key and the right arrow key to jump to the end of a page (End), and Function and left arrow to jump to the top of a page (Home).
• Command + up and down arrow keys to go to Home & End respectively. 

[Manish Maharjan]

Hi @Alastair Wilkes ,

Thanks for your response and acknowledging feedback seriously. Here i have attached screenshot that i meant by file list. 

Left side is the new Pull Request experience and Right hand side is Old Pull Request experience. 

This is just an example where about 141 files has been modified. So From right hand side, features like

- Showing number of lines that has been added/deleted

- Showing comments head icons displaying which files has been changed and how many comments 

-Displaying all these file list hierarchy in the beginning of the Pull request like in right hand side would have been very much beneficial

However, currently in the left side we are unable to see full file path if it is longer. Middle file path is being replaced with multiple dots. This creates a situation where we need to manually open the file and see the full path whenever it is needed. 

Therefore, we would say that we are missing these features and would have been valuable if these features were also ported to the newer version so that users could get nice experience. :) 

Other than that at least we have found new Pull request experience is good. 

Thank you  

[Alastair Wilkes]

Thanks for the screenshots @Manish Maharjan! I understand what you are referring to, now.

When you said file list, I thought you were referring to the (new) file tree (which you can view by clicking on the "141 files" card in the right sidebar), not the list of diffs itself.

But the good news is that we do plan to add the lines changed and comment count info to the diff headers (and the file tree), and we need to make the paths expandable, too.

Thanks again!

[Deleted user]

Just want to echo this comment, after several attempts of real world use I had to disable the new experience because I was really lost without the old full width overview. I scan a lot of pull requests on which I might only be a secondary reviewer just check what areas have been touched.

The side tree is just visual noise at the side for even a moderate size pull request (the one I'm looking at now is 58 files):

• most of my filenames are truncated
  • the use of a tree in a narrow sidebar exacerbates this issue, but they'd still be truncated even if there weren't all indented half off the screen.
• the indenting is too hard to parse
• it's way too long vertically, there's too much vertical padding

None of those problems apply to the old flat file list. 

Happy to provide some side by side screenshots.

[Jiri Hana]

Re truncated files - you can make the side bar wider by pulling it with a mouse. Unfortunately bitbucket does not remember the settings.

Re vertical padding - that's a pain for me too. Would be nice to see configurable vertical padding as in gmail or Google drive.

[Alastair Wilkes]

Thanks both for the additional feedback. We're continuing to iterate on the file tree experience, so this feedback is helpful.

[Manish Maharjan]

@Alastair Wilkes , Is there any eta when those above requested features would be available? Additionally, it really seems like there should be some shortcuts or buttons for expanding and collapsing long list of Pull Requests easily. Whenever there are 100's of files are changed, it seems very difficult to browse through with new Pull Request experience. 

[Alastair Wilkes]

Hi Manish,

Thanks for your comment. We've recently made some improvements in this area:

1. You can expand or collapse all files via a button in the "..." menu on each file
2. We've added lines changed counts to the file tree

We're continuing to focus on large PR reviewability, so stay tuned for more updates. We're planning to persist sidebar width across page loads, which should help.

Thanks,

Alastair

[Manish Maharjan]

Hi @Alastair Wilkes 

Thank you for your response and making aware about those options. Expanding and collapsing seems to be working fine. 

Additionally, with longer file names we could still see that it truncates file name as per aforementioned attached picture and also suffers in loading more than 10k lines of code changes atm.

Hope these issues would be also fixed soon.

Thanks, 

Manish 

[Manish Maharjan]

Hi @Alastair Wilkes , 

Has there been any progress on these issues or are these even in a roadmap? After almost a year, seems like these mentioned issues are still same. 

Would it be too much work to reduce at least unneeded space from the new pull request and making the full path visible?  As you can see from above left screenshot that if there is a file path like, 

Firstpath/Secondpath/Thirdpath/Fourthpath/Finalpath.php

then it creates space like 

Firstpath  /  Secondpath  /  Thirdpath  /  Fourthpath  /  Finalpath.php

 Was there any good reason for this? If not, any possibility to make this minor UI changes so that full path would be visible easily? 

Also, really looking forward to have list of File changed feature from old Pull request. 

Thank you 

[brahmana]

@Alastair WilkesBeen using this new PR UI ever since it came out. Liking it so far and definitely waiting for all those missing features you have already listed.

I have already given a bunch of feedback using the "Feedback" widget and also on twitter. I was then asked to post stuff here for large feedback. Not sure if all these would fall under the purview of the new PR UI, but here it is anyways.

So here is a very long comment. Brace yourself for impact.. :-)

My Workflow

I just wanted to put forth my workflow and wanted to see if I am doing it right or if I can get more efficiency out of the system.

1. On getting a new PR for review, start reviewing and commenting
2. We have a Slack integration which will post each comment to a repo-specific channel (Sub-optimal but better than individual emails)
3. On large PRs I tend to pause after some time and come back to it later. Currently I use the collapse feature in the new UI to mark which files are done.
   1. Initially all files are open. As and when I finish reviewing a file, I collapse it.
   2. The next time I come back to the same PR, I start from the first open file.
   3. It's great that the collapse status is remembered by the system across reloads. Thank you for that.. :-)
4. Once I am done with the PR, I add a comment saying "Review complete" and @ tag the developer.
   1. @ tag helps with Slack notifications.
5. The developer addresses the comments (or asks for clarifications) and updates the PR
6. As and when the developer addresses a comment (or may be after updating the PR), the developer replies to each comment with the text "Addressed"
   1. This is just a safety check to ensure that all comments are addressed. An acknowledgement system.
7. The slack integration notifies me that a PR has been updated.
   1. I  might also get a nudge (on Slack or in real) from the developer. :-)
8. When I start reviewing the updated PR, "Activity Tab" (of the old UI) is my starting point.
   1. I find the last commit made before I started my previous commenting session and check that all comments after that have been addressed satisfactorily. If not, add more comments / follow up comments (in the new UI)
   2. Currently I have the activity tab from the old UI in one tab and the PR diff of new UI in another tab for this.
   3. I then view the diffs for all new commits, i.e. commits added after my last commenting session - to make sure that I am not missing changes not related to my previous comments.
   4. For the previous step also, I use two tabs. One for the commit and one for the PR. I do not comment on commits because they do not appear in the PR.
9. The above process might repeat for multiple iterations till the PR is good to be merged. I then approve it and merge it.

Deficiencies or my wish list :

1. Activity Tab - There has been a large discussion in this comment. I just wanted to do a +1 on the importance of the activity tab and reiterate that the current one in the sidebar is not actually useful. It does not have the full activity. Very common for me to breach the activity count limit on most PRs because of the number of comments I end up adding. In general I would like to see what all has changed since my last commenting session.

2. Review Session - Notification per comment is noisy. Having to write a comment saying "Review Complete" is also somewhat rudimentary. If there can be something like a "Review Session" which I start, add comments, may be delete or edit those too and finally end it, then at the end of the session there is one single notification saying "PR #123 reviewed. 12 comments added" - that would really help.

3. File Review Status - Using the collapse status as a flag to know which file is reviewed and which is not works. But "within a session" if I can have such a file explicitly it would allow me to use the collapse feature for what it was designed - To get a concise view of the PR and navigate easily.

4. Comments as Tasks with status - The "Addressed" reply by the developer to reviewer's comments are again a workaround and rudimentary. If we have an option to mark a comment as "Addressed" and then an option for the reviewer to un-mark it (or reopen it) possibly with a comment or mark it resolved - that would be great. If there is another solution or product in the ecosystem for this, please suggest.

5. Tale of two tabs - For the two use cases above where I mention I use two tabs, if I can do the same (or achieve the same result) without switching tabs, that would be great. I do not have any ideas as to how that can be done though.. !!

If these deficiencies can be met with a change in workflow or the workflow can be changed for the better in general - I am more than happy to hear.

[Alastair Wilkes]

Hi Srirang,

Thanks for outlining your workflow! It helps us understand how we can improve.

Does your team use pull request tasks? Tasks let reviewers call out specific changes they expect PR authors to make, which alleviates the need to go through every single comment in the activity feed and the need to reply to comments with "addressed." I recognize the irony of suggesting a feature that isn't available the new UI yet, but I believe they'd help your workflow.

Aside from that, you're right -- the workflow needs to be improved with changes like you've suggested (review sessions to signal review completion and reduce notifications, and iterative review to let you view and comment on new changes since you last reviewed). Once the new UI is generally available, we plan to focus in this area.

Thanks again!

Alastair
Bitbucket PM

[brahmana]

Hi Alastair,

Thanks for the follow up. I wasn't aware of pull request tasks until another person commented about it on this same post. I will try it out, although going back to the old UI will now be some effort after getting used to the new one.

Really looking forward to the other planned workflow related improvements getting implemented.

Good luck to you guys.. :-)

[Jeremie Rahm]

Hey,

This new PR tool is really fantastic, already so much better than the former one, great job!

I got one small problem, though: with a very large PR (600 files), if I scroll up from the bottom of the PR, it loads the unloaded files and teleports me which can get frustrating. But it's understandable, 600 files is a lot haha

Also, one feature is missing: a "Reviewed" button per file. Once the user clicks on it, the file is collapsed and stays collapsed by default, and it becomes Not Reviewed again if the file changes in a commit after. That helps to unclutter the PR while reviewing a big piece of code, this feature is in Helix Swarm (perforce)

Are you planning on adding that feature, that's the only one thing our team really misses with your tool

Again, fantastic work so far! Thanks, and looking forward to see what's coming next

[Alastair Wilkes]

Hi Jeremie,

Thanks for trying out the new UI and for letting us know your feedback!

Quick question: what do you mean by "loads the unloaded files and teleports me"?

We've hearing a lot of requests for file-level reviews, and it's something we're considering (along with other workflow improvements) for the future once the new UI is generally available.

Thanks!

Alastair
Bitbucket PM

[Joao Squillace Teixeira]

Wondering if there is an ETA to have the new pull request experience with most of the old PR version features?

[Alastair Wilkes]

Hi Joao,

Thanks for your question. The definition of "most" features is going to depend on the team using them, because different teams use different features :) From our perspective, while we've added back most of the major features, we still have a few major ones left, notably

• Word diff
• Likes
• Tasks
• Merge checklist

We plan to implement them in roughly that order, but we can't share an ETA right now. Are there particular features that your team is interested in?

Thanks for trying out the new experience,

Alastair
Bitbucket PM

[Joao Squillace Teixeira]

Thanks for getting back to my question! Definitely tasks and likes are on top of my team's need. I will wait for it :)

[MeijerYoung]

"likes" isn't a productivity tool; it's a social/HR tool.  Why is this being prioritized above tasks and merge checklists?

I understand that some may be using it as a rudimentary acknowledgement system, but it isn't that. 

[Jon]

On one PR I have a binary file that a team member commented on.  In the new PR experience I am unable to see the comment.  It shows a word bubble icon next to the filename in the files card on the right, but when I expand the binary file it just shows a message saying the file can't be displayed, but no comment.

[Alastair Wilkes]

Hi Jon,

Sorry for the issue; we're working on fixing this.

Alastair

[Jon]

On the old PR experience, a querystring flag of w=1 would ignore whitespace.  I see the menu item to ignore or show whitespace, but it looks like it's not picking up on that flag.  Could it be made to?  Even better would be if a cookie could remember the setting across page refreshes so the user doesn't have to jump through that hoop first thing every time the page loads.

[Alastair Wilkes]

Hi Jon,

Thanks for your feedback! Remembering this setting across page refreshes is in our backlog.

Alastair

[Francois Stephany]

We're developing tools to integrate with Bitbucket and would love to extend the new PR experience.

Do you know when external integrations will be enabled?

Will it use the org.bitbucket.pullrequest.overview.informationPanel location property of a webpanel?

[Alastair Wilkes]

Hi Francois,

We're planning to add support for external integrations in an upcoming update, but I don't have an ETA right now. Yes, it'll use the same locations as the classic UI for consistency.

I'd love to discuss what you're building! Shoot me an email if you're interested in chatting about it (awilkes at atlassian dot com).

Alastair

[Georgios Petrou]

How about https://bitbucket.org/site/master/issues/5814/repository-refs-for-pull-requests and https://bitbucket.org/site/master/issues/11976/labels-for-pull-requests ? Aren't these part of the "experience"?

[Alastair Wilkes]

Hi Georgios,

Thanks for your question. This refresh primarily concerns updating the user experience of the pull request page itself, so those features are not considered part of this project.

That said, both are important improvements in our broader project backlog.

Thanks,

Alastair

[sgautrin]

What's the status regarding the implementation of tasks support? I know it's been listed as not implemented yet and coming soon™, but really realised now that I'm back at doing pull request review on bitbucket that this is severly missing (although with the merge checks being gated behind the additional paywall of “premium”, I guess it's less useful).

Although it could be the occasion to remove the clunky task concept all together in favor of [resolvable pull request comments](https://bitbucket.org/site/master/issues/6535/resolveable-pull-request-comments) and finally catch up slightly to competitors on that front.

[Jon]

I ended up hacking together a chrome extension we use that adds a "resolved" button next to each comment thread so the entire thread can be marked as resolved (and given a transparency of 0.5) :)

It broke recently, but it was extremely useful.  Some of our larger PRs would have dozens of comment threads and it would be pretty much impossible to visually pick out which items had yet to be addressed without that.  Fortunately I haven't had such a PR since my script broke.

If you could filter on which comments were resolved that would be fantastic!

[Alastair Wilkes]

Hi y'all,

We're working on some other improvements right now, but tasks are close to the top of the backlog. Stay tuned.

The ability to resolve comments is a great idea that we're considering for the future.

Thanks,

Alastair

[Jon]

Now that tasks are implemented, I can add one to the initial comment in a thread and check/uncheck it depending on whether it's been fully addressed. This is nice, but what is really needed is a way to toggle the comment thread as resolved without having to manually create a task just for this purpose.  It also will keep the actual list of tasks from getting cluttered with these workaround "tasks".

If you find there's not much call for such a feature (maybe there is but task support is "good enough" that people are getting by?) I'm ok hacking together another chrome extension that can operate on the new experience. :)  But I think lots of people would love it.

[brahmana]

@Jon  Please share the chrome extension if you create one.

Also if the old one that you mentioned in your earlier (April 2019) comment is still available, I would love to try that also.

If you can share the source, I would like to see if I can create a Firefox extension based on your Chrome extension.

[Jon]

If I get around to creating one for the new experience I will see if I can share it.

The old one is part of a custom extension our team uses and is very customized for our needs, so it wouldn't be really a good fit for sharing outside our company.  However, I can tell you that the portion of it I'm referring to is pretty simple - just storing key/value pairs of the dom id of the top comment in a thread, a boolean for whether it's been marked resolved or not, and a bit of jQuery to add a toggle button in the header of each top-level comment that persists the boolen and updates itself based on that boolean.  It shouldn't be too hard to put together something higher quality than the code I wrote (mine was pretty messy).

My hope is that the creator of the Refined Bitbucket chrome extension (still in active development) has something in the works for the new UI.  Probably they're waiting for it to settle down a bit before releasing something for it, if they plan on supporting it at all.

[brahmana]

@Alastair Wilkes  The new UI is gone. The option to enable this in the bitbucket labs is also gone.

Does this mean you guys are going for a general public roll out or is something off??

[Alastair Wilkes]

Hi Srirang,

The option to use the new UI will be back soon -- sorry for the inconvenience!

Alastair

[sgautrin]

What's going on with the new pull-request experience? Suddenly I am back to the old experience, with the lab option no longer available (and that with both my work account and my personal account)...

[Alastair Wilkes]

Hi Sébastien,

The option to use the new UI will be back soon -- sorry for the inconvenience!

Alastair

[Jiri Hana]

The nice thing is that it also brought the simple editor back - it is so much easier to use than the new wysiwyg one...

[Alastair Wilkes]

The new UI is now back! Thanks for your patience.

[Maxim Leonov]

Unable to comment on an empty file diff.

Intended or a bug?

It's convenient to be able to comment on such diffs especially if the're mistakenly committed.

[Alastair Wilkes]

Hi Maxim,

Thanks for reporting that. It's a bug; we'll get it fixed.

Alastair

[Jon]

One major issue I'm facing is that the Delete link for comments is immedialy adjacent to the Edit link, and there's no confirmation dialog when you click Delete like on the old experience.   It's too easy to accidentally delete important comments when you really wanted to edit them!  Can you add a confirm on the delete?

[Alastair Wilkes]

Thanks for the feedback -- we're planning to add a confirmation to the delete button.

[Jon]

100 emoji

[Jon]

There's still not a confirm for delete (at least on some outdated comments I just tried it on).  To make it worse, there's no visual indicator that the ajax request to delete the comment has been initiated, so I tried to click it again, but it updated the UI just before I clicked so I ended up clicking the Delete link for the next comment (which I didn't actually intend to delete).  

It reminds me of an LMS that once had a Delete All Users button right next to a very commonly used button in the admin UI.  Less fun. 

[Jon]

@jarredc any word on when this might be fixed?  

[jarredc]

Thanks for keeping me honest here, @Jon

The ticket is in progress right now.

[Jon]

w00t! thanks :)

[Jon]

One thing the old PR experience had that was very valuable was for "Comments on prior versions" there was the ... icon above and below the changes to fetch the next 10 adjacent lines so you could get the context.  

Often for outdated versions of the file that had comments attached the line numbers are quite different, so being able to expand to gain a bit more context is very helpful.  Otherwise we have to guess which commit the old comment was added on and try to find where in the code the comment was added by crawling through the history in git.

[Alastair Wilkes]

Thanks for the feedback, Jon. We'll take another look at this.

[Jon]

Any update on this regression?

[Jon]

@jarredc Any update on this regression?  Looking at an outdated comment with no ability to view more than an arbitrary and small amount of context can make it difficult to tell what the comment is about.  Bringing back the ellipses buttons on the left to load more context would be much appreciated.

[Jon]

Bumping this, hopefully.

@jarredc or anyone at Atlassian - can you comment on this issue?  I've run into it occasionally (just now, in fact) and it's kind of a speed bump in the workflow whenever I do.  I can still get at the info I need if I switch over to git and start looking at file history, but it would sure make the UX better if we could expand the context like we used to be able to.

[Jon]

Another user commented twice on a PR.  They later deleted one of the comments.  It now looks like this, even though the other comment remaining still shows their avatar and name:

Should the deleted comment still show the avatar and name of the author?  They definitely aren't a former user.

The Activity cart on the right also still correctly shows their avatar and name.

[Alastair Wilkes]

We need to improve the "Former user" text, but we don't plan to display the avatar and name of the author on deleted comments.

[Roman Proshin]

Thanks for the great new UI! I really like it! But there is a feature that I miss: I can't see approvals from the pull request author. And it was possible in the old version. And this feature is quite important for our team because we use it as a sign that the pull request is ready for review: if the pull request is approved by the author then it's ready, otherwise the author is still working on/fixing it. Do you have any plans to introduce this feature back in the new UI?

[Alastair Wilkes]

Hi Roman,

Thanks for trying out the new UI.

Yes, we plan to bring that back.

Thanks!

Alastair

[brahmana]

Been using this new UI for some time now and yesterday I faced a major roadblock which forced me to go back to the old UI for one PR.

When a PR is going through more than 2 rounds of review I use the `Activity` tab to look at all the comments from my last review session. For this I look at the commit from the author before my last review session and then I walk up the page till the latest commit.

While the same thing is possible in the "Activity" sidebar of the new UI, unfortunately, it does not actually show the entire comment text with the code context. The "Activity" window only has links, clicking on which the "Previous Comments" pop-up comes up show ALL the previous comments. In that pop-up I do not know which of the previous comments are actually from the last review session only.

I will have to explicitly look at the timestamps of those comments to see which session it very likely was. That is very tedious. The old "Activity" tab gives a complete chronological view of the activities and makes it very easy to focus on the changes in the most recent session.

Further if the comment was on a line which got deleted in a subsequent commit, new UI can't show any code context for that. The old "Activity" shows it. That is very helpful and very much needed.

Please bring both functionality back.

[Alastair Wilkes]

Hi Srirang,

Thanks for your feedback.

The "Activity" window only has links, clicking on which the "Previous Comments" pop-up comes up show ALL the previous comments. In that pop-up I do not know which of the previous comments are actually from the last review session only.

After the pop-up opens, it should scroll you to the comment you clicked on. Is that not happening?

Further if the comment was on a line which got deleted in a subsequent commit, new UI can't show any code context for that.

We'll look into this. Thanks!

[brahmana]

You are right. It is scrolling to the relevant comment. Whatever workflow I described is still possible with the new UI. I think I just need to update my mental model.

Only thing is it slows down a bit with the "Click -> Throbber -> Pop up appears -> Close" cycle where as the in the old UI it is just "Scroll up". But that's just a trade off I suppose.

[Jon]

Right now the Activity card fails to load for me on all PRs or I'd go look, but I'm wondering if the clicked comment is not just opened and scrolled to, but also highlighted.  That would be super useful if there are more comments in the popup than one.

[Roman Proshin]

The new UI is getting better every day! However, one feature is still missing for me (even the old UI didn't have such a feature) and that's about marking a comment as "done". In the old UI I was using "Like" button to do that: when a comment for a pull request is fixed - I clicked the "Like" button and that was a way to let to the reviewer know that this comment is fixed. In the new UI there is no such button yet, but you have a plan to implement it (in "What's missing?" topic). However, I would like to have a dedicated option for that. And I'm sure many other devs would like to have it as well.

Thank you!

[Alastair Wilkes]

Hi Roman,

Thanks for the feedback! We plan to replace "Likes" with emoji reactions in the future.

We're considering other workflow improvements in this area, but we need to work through some other items first.

Thanks,
Alastair

[Jon]

On the old PR experience, clicking the side-by-side diff would allow you to scroll both sides at once.  That was intuitive and very useful.  You could also see the entire file.  In the new experience they're disconnected and you have to click the ellipses a lot to load more code.  In large files this is painful if you want to see a lot of context at once like in the old experience.  Can that be brought back?

[Alastair Wilkes]

Hi Jon,

Thanks for the feedback. We plan to circle back to the side-by-side diff after we've worked through some other items. We'll take a look at scrolling improvements at that time.

Thanks,

Alastair

[Jon]

Any update on this?

[Jon]

@jarredc is bringing back this feature still on the table?

[Ed Lomonaco]

can the deleted files be collapsed by default? it'll make reviewing important things easier

[Alastair Wilkes]

Hi Edward,

Deleted files should be collapsed by default. Are you seeing something different?

Thanks!
Alastair

[Ed Lomonaco]

yup, it shows the deleted file, which I collapse when I see it

[Alastair Wilkes]

Thanks, we'll take a look.