15

When flagging a question or answer on stackoverflow.com or even meta.stackexchange.com and some other sites (didn't test more of them), each time the Flagging modal has to be re-rendered completely, it appears 59 pixels lower than the past one, causing it to slowly go away to the bottom of the page while navigating through its links.

Here's an image that explains it : Clicking on links in the modal

The easier way to reproduce it is by simply clicking successively between "Should be closed" and the "Flagging" breadcrumb link.

  • 2
    Repro-ed in Chrome/Win10 – rene Nov 23 '17 at 17:07
  • 1
    Hmm, thought this was only a Stack Overflow bug, but I'm seeing it here now. It has already been reported on MSO here. – Laurel Nov 23 '17 at 17:12
  • 1
    The issue is still there. – Sebastian Simon Jan 8 '18 at 21:24
  • 1
    Fixed in the next build. Ilmari Karonen's answer is spot on. – balpha Jun 13 '18 at 10:32
  • 1
    @balpha when will you finally recruit him? :) – Shadow The Curly Braced Wizard Jun 13 '18 at 10:35
  • @balpha When will that build go live? I currently still see it and after the new nav update it's a lot worse :( – André Kool Jun 13 '18 at 11:12
  • 3
    @AndréKool I'm deploying this and a bunch of other fixes now, so it should be live in a couple of minutes. – balpha Jun 13 '18 at 11:53
10

The problem is that the flag_showCloseDialog() and flag_showCloseDialog() functions in 05_VoteToCloseAndFlag.js (included in full.en.js), which are responsible from switching from the flag popup to the close vote popup and back, are using jQuery .offset() instead of .position() for determining the position of the old popup. Thus, they end up determining the position of the popup within the page rather than within the offset parent element. Then they use those values to set the CSS top and left properties of the new popup, which of course adjust the position of the new popup relative to the offset parent.

Presumably, this was not a problem in the past, since the offset parent of the popups (which are actually attached to the "flag" link in the DOM) used to be the whole page, or at least some element positioned at the top left corner of the page. But with the new top bar redesign, the offset parent is now the <div class="container"> element, which has a top margin of 40px to accommodate the top bar.

The obvious solution is to fix those two functions I mentioned above so that they'll call the right jQuery method. I have tested this (using an ugly browser dev console hack) and can confirm that it indeed fixes the bug. For SE devs' convenience, here's a ready-to-apply patch:

--- 05_VoteToCloseAndFlag.js    2017-11-24 09:05:36.381104431 +0200
+++ 05_VoteToCloseAndFlag_fixed.js  2017-11-24 09:06:25.465518105 +0200
@@ -236,7 +236,7 @@

     function close_pushFlaggingBreadcrumb() {
         close_pushTitleBreadcrumb("Flagging", function () {
-            var location = _closePopup.offset();
+            var location = _closePopup.position();

             if (!StackExchange.options.isMobile) {
                 _flagPopup.css({ top: location.top, left: location.left });
@@ -712,7 +712,7 @@
     };

     var flag_showCloseDialog = function (radioLoadClose) {
-        var location = _flagPopup.offset();
+        var location = _flagPopup.position();

         var deferred = _flagPopup.fadeOut('fast').promise();

Ps. As of v1.50, my SOUP user script now contains a fix for this bug. It's basically the same as the "ugly browser dev console hack" I mentioned above, and works by monkey-patching jQuery's .offset() to act like .position() when called on the flag or close popups.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .