Editor's sticky header wrongly positioned

[carlosesilva]

Hello there,

I work for Boston University and we are in the process of integrating your plugin into our platform.

We have found an issue where the editor's header (sometimes the footer as well) gets absolute positioned in a weird spot. It happens if a post has enough content to trigger the editor's header sticky mode when you scroll down the edit page.

This issue was confirmed to happen on a fresh install of WordPress with only the all-in-one-video-pack plugin installed (confirmed on both v2.7 and v2.8-rc.4).

We have found that the issue gets fixed when we remove the css rule body{ overflow: auto; } found here: https://github.com/kaltura/all-in-one-video-pack.wordpress/blob/master/css/admin.css#L4

I don't see why a plugin would need to add styles to the html and body tags anyways. Unless there is a very good reason to have them, I believe those styles should be removed so that this issue gets fixed. I will be submitting a pull request shortly after this with the proposed fix. In the mean time I will be adding some more information about the issue below.

How to reproduce the issue

1. Activate all-in-one-video-pack.
2. Go edit a post that has a lot of content (enough that you need to scroll down to see it all).
3. Scroll down so that the editor's header enters the sticky mode.
4. Scroll up to the top of the page. The editor should appear broken now.

Screenshots of the issue in action

Visual view Text view

Environment tested on

• WP Version: 4.8.3
• PHP Version: 7.1.7
• Plugins activated:
  • all-in-one-video-pack (v2.7 and v2.8-rc.4)
• Browser: Chrome 62.0.3202.89 (Official Build) (64-bit)

[kaltura-hooks]

Hi @carlosesilva,

Thank for you reporting an issue and helping improve Kaltura!

To get the fastest response time, and help the maintainers review and test your reported issues or suggestions, please ensure that your issue includes the following (please comment with more info if you have not included all this info in your original issue):

• Is the issue you're experiencing consistent and across platforms? or does it only happens on certain conditions? please provide as much details as possible.
• Which Kaltura deployment you're using: Kaltura SaaS, or self-hosted? If self hosted, are you using the RPM or deb install?
• Packages installed. When using RPM, paste the output for:

  # rpm -qa \"kaltura*\"

  For deb based systems:

  # dpkg -l \"kaltura-*\"

• If running a self hosted ENV - provide the MySQL server version used
• If running a self hosted ENV - is this a single all in 1 server or a cluster?
• If running a self hosted ENV, while making the problematic request, run:

  # tail -f /opt/kaltura/log/*.log /opt/kaltura/log/batch/*.log | grep -A 1 -B 1 --color \"ERR:\|PHP\|trace\|CRIT\|\[error\]\"

  and paste the output.

• When relevant, provide any screenshots or screen recordings showing the issue you're experiencing.

For general troubleshooting see: https://github.com/kaltura/platform-install-packages/blob/Jupiter-10.13.0/doc/kaltura-packages-faq.md#troubleshooting-help

If you only have a general question rather than a bug report, please close this issue and post at: http://forum.kaltura.org

Thank you in advance,