Possible to navigate to raw JSON when merging MR & removing source branch

I can reproduce locally and on GitLab.com with the following steps:

1. As an administrator, navigate to an MR you can accept
2. Select "Remove source branch" and accept the MR
3. Wait for merge to finish, then hit the browser's back button 1-2 times

I cannot reproduce the bug when "Remove source branch" is not selected.

changed title from Possible to navigate to raw merge request JSON with browser back/forward to Possible to navigate to raw JSON when merging MR

changed title from Possible to navigate to raw JSON when merging MR to Possible to navigate to raw JSON when merging MR & removing source branch

added reproduced on GitLab.com label

added ~13921 label

changed milestone to %9.0

mentioned in issue #28772 (closed)

assigned to @brycepj

Smells like another one of those: #20289 (moved)

@winniehell I think you're right. Is it worth keeping this open?

@brycepj Until now, we fixed them one-by-one.

removed assignee

added frontend label

This is suuuuuuuppppperrr old. @DouweM and I have been seeing this around forever

@jschatz1 If I correctly understood what's happening, we are moving away from those JSON URLs and use serializer (or the API) instead. So doing such a refactoring could be used to solve this, right?

Trying this out on master: I am unable to reproduce on a project with and without GitLab CI setup.

1. (location after clicking "Accept merge request") http://localhost:3000/group/project/merge_requests/3?deleted_source_branch=true
2. (Back 1, normal MR) http://localhost:3000/group/project/merge_requests/3
3. (Back 2) wherever you were at before moving to the MR to accept it

---

What link are you seeing the JSON on? What JSON is it?

The new MR widget will probably change/fix things.

---

• https://gitlab.com/gitlab-org/gitlab-ce/issues/27932
  • https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9105
• https://gitlab.com/gitlab-org/gitlab-ce/issues/20289

@MadLittleMods The raw JSON of the merge request would show up if http://localhost:3000/group/project/merge_requests/3 is loaded with Accept: application/json. Those requests usually happen in Ajax calls. However, I couldn't find a corresponding call now when quickly browsing through the code of the merge request page.

@winniehell Are you still able to reproduce?

Are you still able to reproduce?

@MadLittleMods No, but I also wasn't able to reproduce when the issue was created. In #17365 (closed) the JSON was only displayed some times...

I was able to reproduce this today on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795

@ClemMakesApps I'm not sure this is the same issue. What your GIF shows looks like https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795/pipelines with Accept: application/json. For me it always loads https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795/pipelines.json though.

Hmm okay, I will create a new issue then @winniehell

@ClemMakesApps Sorry, it may indeed be the same issue. Both URLs (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795.json and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795/pipelines.json) are fetched by IssuableTimeTracking. Could it be that gl.IssuableResource.endpoint sometimes points to the URL without .json appended?

Related: https://gitlab.com/gitlab-org/gitlab-ce/issues/29410

I did some further digging:

• gl.IssuableResource.endpoint is initialized in _sidebar.html.haml
• it is set to issuable_json_path which comes from issuables_helper.rb
• this should always be something like https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795.json and never https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10795/pipelines.json

So my wild theory here is that

• the Ajax call happens before gl.IssuableResource.endpoint is set
• so undefined is passed as URL to SubbableResource.get
• this leads to the awkward behavior of $.ajax which defaults to location.href if no URL is set (see !4642 (closed) for details)

This theory still doesn't explain how it happens but it would explain the behavior.

assigned to @psimyn

@ClemMakesApps can you reliably reproduce on that MR? I've tried in chrome/ff/safari but it is always ok

mentioned in issue #30599 (closed)

removed assignee

I was able to reliably reproduce it yesterday. Haven't tried today yet. If it is what @winniehell is observing, my changes for multiple assignees and refactoring time tracking may fix this issue but that won't get in until 9.2

mentioned in issue #31302 (closed)

I can't reproduce this locally. Any more tips for reproducing?

Is there a chance this is now fixed because of the MR widget refactor? /cc @fatihacet

@lbennett The MR widget refactor hasn't been merged yet, so that wouldn't have done it.

And I just reproduced on master. The steps in the description still work for me:

I still can't repro this. D: Do you know if the MR widget refactor would solve this? If so we can add Closes #... to the MR and get this regression assigned to fatih.

I cant reproduce it, but I can see why it is doing it. Not sure if the new widget will fix this, but regardless of that this is a regression that need to fix.

assigned to @iamphill

mentioned in commit 58e36044

mentioned in merge request !11096 (merged)

closed via merge request !11096 (merged)

mentioned in commit 05919a01