Overlay scrolls when vex modal exceeds viewport height

[raddevon]

If the modal exceeds the viewport height, the overlay scrolls when scrolling the modal leaving part of the underlying page without overlay coverage. It's my understanding that this is caused when a transformation of an element creates a new stacking context causing position: fixed to be ignored.

I've tested this in Chrome, Firefox, Opera, and Safari. All the browsers except Firefox exhibit this behavior. In Firefox, scrolling the modal will not scroll the overlay, but the scroll must originate from the modal and cannot be focused in the overlay itself. I.e. I must have my pointer inside the modal to scroll it in Firefox.

I can remove the perspective property from the CSS of the modal to fix the problem in the other browsers, but, as is the case with Firefox, scrolling can then only happen inside the modal. This may be preferable to leaving part of the page exposed outside the overlay. An ideal solution, IMHO, would allow for scrolling of the modal even while focused on the overlay, but the overlay itself would remain fixed.

It may be possible to remove this property after the animation is complete to "fix" the issue (although scrolling of the modal would still require focus to the modal itself). I will fork the project and try to test this as a viable solution.

[adamschwartz]

Thanks @raddevon for submitting this issue. I have noticed it as well and will look investigate further.

A potentially-related issue which may complicate the matter is when mobile/touch behavior comes into play. If I remember correctly, scrolling the overlay on iPad can cause the overlay to move with respect to the window's coordinate system, exposing the underlying page in a similar way.

[raddevon]

I'm happy to, @adamschwartz. I've taken a look at the code just now, and I'm not sure I'll be much help. I have a general idea of what needs to be done, but I'm not sure I have the chops to write it. Also, I'm only somewhat familiar with CoffeeScript which doesn't help matters. Seems like there should be a way to apply a different class along with the user's afterOpen callbacks, but I'm not sure how to implement this. Even then, I'm not sure how that would impact mobile browsers given your point about that similar issue above.

If you think there's some way I can help despite this, I'd love to, but I may need some guidance.

[acornejo]

Hi @adamschwartz

After stumbling upon select, I browsed the HubSpot repositories to see if there was anything else useful for me. I'm stoked about using Vex and messenger in future projects (too late now since I used boostrap modals and toastr).

Anyway, this scrolling problem seems similar to the one I reported on select. I think it could be fixed in a similar way (tweaking the css of overlay, body and modal). If no one else is working on a fix, I could do a pull request whenever I get a chance to fiddle with Vex.

[adamschwartz]

That would be awesome @acornejo. Although this one has an additional problem relating to the rending context the perspective property creates. I believe ultimately more than one fix will be necessary here.

[LOZORD]

I've found a hacky way to ensure the overlay covers the entire page beneath the modal:

$('.vex-overlay').height($(document).height());

I put this code after the vex.dialog.open call.

It works pretty well. If there's a more elegant solution, please let me know!