Modal dialog position after ajax load is not refreshed

The patch in #1 fixed the issue perfectly for me.

This somehow related to Chrome bug with outerWidth and outerHeight.

    var mdcTop = wt + ( winHeight / 2 ) - (  modalContent.outerHeight() / 2);
    var mdcLeft = ( winWidth / 2 ) - ( modalContent.outerWidth() / 2);

Either outerHeight() or outerWidth() return NaN and only when code turns to:

    var mdcTop = wt + ( winHeight / 2 ) - (  modalContent.outerHeight(true) / 2);
    var mdcLeft = ( winWidth / 2 ) - ( modalContent.outerWidth(true) / 2);

everything start work. Patch is attached, please review.

Applying another patch with yet one fix for window resizing.

The patch in #5 works great for me in Chromium 32 on Linux, without it the outerHeight() and outerWidth() methods appears to return the element instead of a numeric value.

Sounds like this could affect #1294478: Modal dialog dynamic resizing as well.

I re-rolled against -dev -- before committing I need some folks to test against IE, Firefox, and Safari -- more than just chrome.

Hello, japerry.

Unfortunately patch #7 will not fix issue described in task.

It partly fixed in patch #1.

     // top of a form, etc.
     $('#modal-content').html(response.output).scrollTop(0);
     Drupal.attachBehaviors();
+    modalContentResize();
   }

But such fix will ignore fixed (position: fixed;) elements at the top, for example fixed top menu in bootstrap.

Please check attached patch, with proper fix. It will respect fixed position for top elements.

Module ajax_register can be used for quick testing. It will open modal window after click on "Create new account" link in "User login" block. Without patch modal window will not be in center, but at the bottom part of the screen.
If needed I can also provide link to real project which using this fix.

Thank you.

Reroll of #9 after #2280853: Keyboard trap when using ctools modal was committed.

I am experiencing this issue in Chrome and Firefox, but only on Linux. It works fine on Chrome and Firefox in Windows (haven't tested Mac). In my case, I'm using this module to generate modals for selecting entities in an Entity Reference field: http://drupal.org/project/entityreference_view_widget

When I open the modal, the top left corner of the modal is in the middle of the screen, and the rest of the modal is off to the right and bottom - so only the top left quadrant of the modal is visible/accessible. The View that is loaded in the modal has Ajax enabled, and when I modify one of the exposed filters it causes the modal to jump back to where it should be.

This sounds like the same issue described here, however the patch in #10 does NOT fix the issue for me. And the patch in #7 no longer applies.

My site uses the Bootstrap theme, and the Navbar module, if that helps at all.

I manually applied the changes from patch #7, and they also do not fix the issue for me. My ctools modal is only 1/4 on the page, the other 3/4 are off to the right and bottom. Because the left-corner of the modal is centered in the page.

If I resize the browser window, it corrects itself. So it just seems that the code for correctly positioning the window is not firing after the content loads.

Well, I figured out a way to make it work - but it ain't pretty. Patch attached... but I'm leaving this as Needs Work because this is NOT the way it should be done, I don't think... I'll leave it up to someone with more knowledge to make the final call.

Basically, I found that the patch in #10 DOES indeed work - but in my case we need to wait a split second before executing it. So I wrapped the code from #10's patch in a setTimeout() with a 100 millisecond delay... (told you it wasn't pretty).

I don't know why this is necessary... but it is. The patch in #10 alone does not work for me. In testing, I discovered that the $(window).trigger('resize'); was running BEFORE the modal was actually visible, so it wasn't having any effect.

Any ideas?

The really weird thing here is... if you play with the timeout it affects how close to center the modal ends up. The higher the timeout, the closer it is to centered. Waiting a full 1000 milliseconds puts it dead center. 100 milliseconds is actually not quite centered (close enough for me). 10 milliseconds is less centered. So it's as if the modal is traveling from the bottom right up to the center, and depending on when you trigger the resize you can capture it along the path it's taking.

Maybe this is obvious... I just don't know enough about how Ctools modals work to understand it.

I have the same issue than m.stenta using entityreference_view_widget but 100ms does not always solve it. The issue can be caused by other scripts which use delay to and time the browser take to execute scripts.

Instead of waiting arbitrary 100ms, i check every 10ms if modal is centered and try to center it until i consider it's centered.

This works, modal is centered and accessible but a better solution should be found to avoid modal to jump from different places.

I'm having an issue with the modal top style not adjusting after ajax load. The previous patches helped, but it was giving a negative top value. This is what fixed it for me.

@brant.darilek do your patch is to use with #15 or is a replacement ?

I merge #15 with #16 and add a fix when modal content is not available yet.

1. +++ b/js/modal.js
   @@ -314,6 +315,39 @@
   +    var windowCenter =  $(window).width() / 2;
   

   Could we move these two lines down below the modal existence check?

2. +++ b/js/modal.js
   @@ -636,7 +670,7 @@
   +      modalContent.css('top', (mdcTop < 0 ? Math.abs(mdcTop) : mdcTop) + 'px').css('left', mdcLeft + 'px').show();
   

   Would much prefer the ?: operator was not inline here.
   Also, wouldn't '0' be better than Math.abs(mdcTop)?

I have a problem in the mobile version. My modal window does not have the right dimensions. I made changes to the code to fix the problem.

Oops. I added a comment in the wrong issue. sorry.
it's for https://www.drupal.org/node/1294478.

Good idea @GoZ. I tried your patch from #18, but it doesn't work for me.

I traced it to this line:

if ($modal_content.offset().left > 0 && (diff > 1 || diff < -1)) {

In my case, those values are:

$modal_content.offset().left: 737.9927978515625
diff: 0.0072021484375

It looks to me like the top left corner of the modal is centered in the window, so maybe it is using that instead of the actual center of the modal.

Hmm - odd... it appears that it thinks the window and the modal are both ~738 pixels wide... but neither of those are true. If I look at the window size after pageload, it is 1477.69, and the modal is 1182.39.

Confusion.

Edit: Oh I see now that it is dividing the window size by 2, hence the ~738 number.

It turned out that in my case the width of my modal was starting out at 2 px (presumably because it gets populated after being loaded - I'm using the Entityreference View Widget module).

Attached is a new patch that ALSO checks to see if the width of the modal is less than 10 (this is just a rough guess - not sure what the "right" value to check here would be), and if so then it also considers the modal uncentered, so it gets entered into the queue in the same way.

This fixes the issue for me (and centers the modal perfectly, as opposed to my original patch, which just got close to perfect).

I also incorporated the changes requested by @rivimey in #19 above.

Please review!

Ah ha! I missed @rivimey's last comment:

Also, wouldn't '0' be better than Math.abs(mdcTop)?

Indeed it would be! With Math.abs(mdcTop), I am experiencing the modal going off the bottom of the page. And because that's where the submit button is, I can't submit the form in the modal!

Here is another patch that changes Math.abs(mdcTop) to 0.

Attached this to success callback and worked:
$(window).trigger('resize');

@m.stenta #25 didn't work for me. I am experiencing this issue when trying to add new items on a panel page with ipe.

The problem, in my case, appears to be, that any centering happens before modal animations are finished. I have created a very simple patch that addresses the issues I am having. It also uses the previously suggested window resize after any animations have been forced to stop.

Rerolled patch in #25 to apply against latest 7.x-1.19 release.

@lauris.kuznecovs and @kryp71c: I haven't explored your ideas - so this isn't a comment on their merit - I just need a patch for my distro so I can roll out a new release. I will leave it to others to explore your suggestions. We are working on an upgrade to Drupal 9 soon so this issue isn't a priority for us anymore.