Sticky diff file headers within MR tab broken in Safari

When viewing a diff tab in a MR, the file headers appear to be displaced by about 100px and are not "sticky" as they should be. I'm not sure if the position: sticky polyfill is broken here or if there is some other problem. This appears to be a regression in %11.8

Noticed in: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9468/diffs with Safari 12.0.1

added browser:safari diff frontend merge requests regression regression:11.8 typebug labels

added reproduced on GitLab.com label

This problem does not exist in Chrome. I have not tested other browsers.

I am seeing similar things, but it only happens on 11.9 (staging) not 11.8 (production).

• Example that is broken: https://staging.gitlab.com/gitlab-org/gitlab-ce/merge_requests/14774/diffs
• Example that works: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24406/diffs

Could it be that your are seeing things in canary?

This is broken on gitlab.com, it's really bad.

I think OP is mistaken about it being 11.8, I think it's a regression in 11.9.0-rc3-ee - it only appeared on gitlab.com within the last 24 hours.

Example that is broken: https://gitlab.com/fintechlabs/fapi-conformance-suite/merge_requests/432/diffs

@lulalala your link, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24406/diffs - is broken for me:

Have you got old stylesheets cached for gitlab.com, perhaps that is why it appears to work for you?

It seems to be specific to Safari, Chrome seems okay.

added regression:11.9 label and removed regression:11.8 label

mentioned in issue #58651 (closed)

This bug prevents our tream from doing proper MR reviews at the moment. I'm sure this is getting highly prioritized!

/cc @jramsay

added Create [DEPRECATED] devopscreate labels

marked #58651 (closed) as a duplicate of this issue

Observing the same issue in Safari. Only appeared recently.

I'm using Safari and it's just horrible right now!

This is why I suspect it has something to do with the position: sticky property. Safari still requires position: -webkit-sticky, but it looks like we removed it with !25266 (merged).

Is our auto-prefixer config supposed to be adding this back in during the compile step? /cc @timzallmann

Have you got old stylesheets cached for gitlab.com, perhaps that is why it appears to work for you?

I think yesterday gitlab.com was still on 11.8, that's why it worked then.

@mikegreiling We don't have a autoprefixer

I'll make a merge request to fix this. Probably broke other places as well.

assigned to @iamphill

mentioned in commit iamphill/gitlab-ce@31d11ea0

mentioned in merge request !25913 (merged)

In case it will be helpful: at the same time sticky headers broke some icons have stopped rendering as well (at least in Safari) on gitlab.com

mentioned in commit iamphill/gitlab-ce@cf05e49f

closed via merge request !25913 (merged)

mentioned in commit c8116ebd

mentioned in issue #58724 (closed)

mentioned in issue #57691 (closed)

mentioned in issue #58754 (closed)

I still can't review Merge Requests in my company as this bug leads to floating elements overlaying the source code changes. That'a a huge blocker!

What's your time plan for this issue?

marked #58811 (closed) as a duplicate of this issue

What's your time plan for this issue?

@larsblumberg The plan would be that it lands in the next RC on gitlab.com and will then be released with 11.9 (on the 22nd).

changed milestone to %11.9

@larsblumberg I know this is not ideal, but one thing that you can do to temporarily fix this when you're on a page where this is happening is to open the browser console (⌥ Option + ⌘ Command + C) paste the following, and hit enter:

document.querySelectorAll('.diff-file .file-title, .diff-file .file-title-flex-parent, .mr-version-controls').forEach(e => e.style.top = 0)

mentioned in commit e9dfe90b

mentioned in issue #58723 (closed)

This bug was reported on 5th and will be fixed only on 22nd for gitlab.com users.

While I understand that you have a standardized release process, I find it horrific that it takes you 15 days to fix a crucial bug which prevents central parts of your platform - reviewing merge requests - to work properly. I wished you had a way to deploy hot fixes.

While I still believe that gitlab is a great alternative for gitlab, you want to make sure that you're constantly delivering a high quality product and fixing bugs quickly. Otherwise people might move back to github. We once used bitbucket and due to its instability migrated all repositories to gitlab. With gitlab being very open to suggestions and extending their platform, you want to make sure that your product remains competitive.

This bug was reported on 5th and will be fixed only on 22nd for gitlab.com users.

I think you misunderstand. The bug exists in the release candidate version of GitLab 11.9 currently running on GitLab.com, and we anticipate that it should be fixed in a future release candidate between now and the 22nd (when 11.9 is finalized).

you want to make sure that you're constantly delivering a high quality product and fixing bugs quickly

@larsblumberg Thank you for your feedback and concerns!

The bug was actually fixed within one day and included in 11.9 RC5 which is currently being packaged before deployment to our staging environment. If you like, you can follow the release process in gitlab-org/release/tasks#702 (closed). How fast the fix will land on gitlab.com depends on whether we find critical bugs in our staging environment. It's clearly in nobody's interest to deploy this bug fix faster but have other things broken in exchange.

mentioned in issue #58861 (closed)

Thanks for clarifying everyone! I know that releasing is hard you don't want to break anything. I appreciate your great work!

So I'm disappointed that it takes so long to roll out the deployment which includes the bug fix. Today it's 7 days after the bug has been fixed, but it's not yet deployed to gitlab.com - due to obvious reason you mention. Still, this is such mayor bug that I'm wondering how I would manage the deployment process so that Safari users are not blocked that long to be able to review Merge Requests again.

@larsblumberg If you have any suggestion on how to improve our process, we would be more than happy to know. Please consider opening a separate issue for that though because it's getting slightly off-topic here.

EDIT: sorry, reopening the issue was not intended.

reopened

closed

marked #58910 (closed) as a duplicate of this issue

mentioned in issue #58910 (closed)

marked #58904 (closed) as a duplicate of this issue

mentioned in issue #58904 (closed)

mentioned in issue #58986 (closed)

marked #58986 (closed) as a duplicate of this issue