Overlay (and other iframe) scrolling overlaps the toolbar

is this about the flickering u get between the toolbar and overlay when u scroll? coz that might be a FF issue we can't work around using CSS, but I'll look into it

ok, this is some of the weirdest sh*t I've seen in my life, chased this down with my trusted firebug at my side and this change causes me to be unable to reproduce it, however stupid it may seem. It also didn't change anything, which makes me wonder why it was there in the first place -> needs testing in other browsers

I also did not manage to reproduce it with limited markup/css so I can't even attempt to file this as a bug to mozilla

oh btw some background:

removing all text from the elements with overflow:hidden also does the trick, the overflow:hidden on div#toolbar div.toolbar-menu span.toggle doesn't seem to affect it, so it must also have something to do with the styling on the menu items, I'm definately going to look into this a bit more until I manage to reproduce it in a less cluttered context

and 4 days later I realize I forgot to change the status -_-

btw, the link in the first post isn't right, should be http://www.screencast.com/users/Bojhan/folders/Jing/media/0decb1c8-87d8-...

well, I still am trying to understand the issue and why this fixes it, but I am still unable to reproduce this in a controlled environment, so don't be surprised if something causes this issue to resurface

my god, it took me almost a month to isolate it, but I think I've managed to identify the minimum amount of triggers needed

basically it comes down to this:
- Have one bit that's either position: absolute or fixed
- Have that bit contain an element that has its overflow property set to anything besides "visible" (which is the default)
- Have a scrolling bit that also contains an element that has its overflow property set to anything besides "visible"
- Have both bits contain text

isolated example: http://jsbin.com/okaya (http://jsbin.com/okaya/edit for sauce)

clicking the "Click me" will simply remove a class from the <p> inside the green #content area which will remove the overflow: auto; from those paragraphs, causing the bug to go away

alternate solution would be to remove overflow:hidden off the top bit (which I did in the patch in #3)

marking this as fixed, pretty sure this won't re-emerge unless we re-introduce the exact same conditions

filing this as a bug in firefox

Tentatively reopening this, since I'm still seeing it in FF 3.0.15 on Ubuntu Hardy (but then again, I've got other overlay problems that no one else can reproduce either...)

FWIW, I'm seeing it too with FF 3.5 on Kubuntu Jaunty. I'm not experiencing David's huge performance impacts of the overlay in general, though.

Note: I can also reproduce this issue with other iframes, not just the overlay (for example, a WYSIWYG).

So as already suspected above it's really more of a toolbar.module issue - but best to leave it here where people will find it.

I can manage to reproduce this on FF 3.0.x on Ubuntu

some quick tests did not resolve the problem

back to the drawing board q.q

I just posted this over at #615130: Overlay locks up the browser and consumes 100% of CPU for certain browsers/graphics cards/operating systems, which was apparently the wrong place, so I am cross posting here for completeness sake...

Also verifying this is a Major issue for me. Currently, if I'm doing anything in my D7 environment, I have to disable the overlay - the flickering when scrolling is distracting.

My setup:

Dell XPS M1330
Ubuntu Karmic
NVIDIA 185 driver
Firefoxx 3.5.5

I have tried all the patches on this issue and none of them seemed to make the slightest bit of difference.

* When the overlay first loads I see a large spike in CPU usage (up to 50% or so).
* If I sit there constantly moving the scroll wheel, CPU sits at 50%.
* When I scroll quickly, the top of the overlay appears to 'flicker' - sometimes appearing infront of the toolbar, sometimes half infront of it, and sometimes behind it (looks like it takes a few miliseconds to move itself behind the toolbar for every movement)
* When I scroll very very slowly, I can see what it happening a little better... For a split second, the entire middle section of the toolbar actually moves with the overlay, only to move back to it's proper position after a few miliseconds. As I increase the scroll speed, the 'flicker', or 'jumping' of the toolbar get more pronounced.

With the SeaMonkey web browser, there is no flickering, and no movement of the toolbar, however scrolling is slow - about 1/4 the speed of scrolling a Google search results page.

Take a look at this screencast so you can see what I see:
http://www.screentoaster.com/watch/stVkxcRUFIR19fR1xfXF9RXlZW/d7_overlay...

Let's actually move this to the correct queue and give it a better title, since as per the above discussion, it doesn't seem like any fix that is limited to the overlay module will be a complete solution.

Blogpost about what I think is the reason of the bad performance:
http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-perf...

Crosspost patch from #615130: Overlay locks up the browser and consumes 100% of CPU for certain browsers/graphics cards/operating systems, not setting it to review since this is a dirty workaround at best, and it's not in the right place since more things than just the overlay are impacted.

However, the general idea behind the patch (remove the position fixed once an iframe comes up) did solve jerky scrolling for me which happened with both the overlay and toolbar open in opera 10 and firefox 3.5.

In response to #16: That blogpost has a lot of general info on bad performance, I can't really find "the" reason for bad performance we're having. But yea, it's most likely a clash of the js and css code...

@Kiphaas7: That is a definite improvement - I can actually use that without cringing :) Actually, I quite like the way the toolbar disappears when scrolling like that as it means I can see more of the overlay. I always thought it looked it a bit odd with the toolbar always remaining fixed to the top, but I can understand why it should from a usability point of view.

Something that could also be looked into, is instead of going for a js solution, with it's lag/redrawing issues (that's why I'm hiding the toolbar on scroll in the patch), we could look for pure css solutions. One thing that sprung into my mind was modifying a so called "sticky footer", instead of using position:fixed, allthough I did not think of an easy and robust way of using that here. Figures, the usecase does not apply here....

Frankly, my own patch with the hide/show is getting annoying after a while. But then again, it was never intended as a commit patch.

Recreated a very simple page, with an overlay, and dummy modal window. Also created a dummy toolbar (with position:fixed). Then added box-shadow to the modal window. Mind you: no javascript or iframes were used at all!

Results I got were very similar to what I experience with the drupal overlay.

1. The actual overlay (that div with an opacity of 0.7) doesn't influence performance at all.
2. Firefox scrolling is very jerky with box-shadow, it's fine (if you pay really close attention, there is still some lag, but dismissable) without box shadow.
3. Opera is quite jerky, that stems from the toolbar. Removing the fixed position on the toolbar makes opera scrolling super-smooth. Opera does not support box-shadow, so that is a non-issue.
4. Firefox scrolling also becomes super-smooth WITH box-shadow and WITHOUT position:fixed on the toolbar.

I'm testing this on a e6600 intel core2 duo pc, with a screen resolution of 1280*1024. GPU performance isn't important yet, since those developments are still in baby-shoes. I suspect that with higher screen resolutions and/or lower spec machines, the performance degradation will be worse, since this is a reflow/repaint issue. Substantially more elements on a page should also lower performance (comparing my simple testcase with drupal).

So the way I see it, we have a few options (but please, come with more ideas!)

1. Remove the toolbar's position:fixed. Pro: smooth scrolling everywhere, overlay js code can be simplified. Con: you have to scroll all the way up to reach the toolbar.
2. Remove the toolbar from sight while scrolling (like my patch, but then in a non annoying way). Pro: smooth scrolling, toolbar is still always in sight (after scrolling). Con: it comes out of nowhere when done with scrolling, high risk of annoying the user.
3. Emulate position:fixed with jquery. Unfortunately, there will be lag visible when the position is updated via jquery.
4. Emulate some sort of frame layout Pro: smooth scrolling, toolbar always available. Con: huge chance of browser inconsistencies, and a second set of scrollbars(yikes!).
5. Add a switch to the toolbar that switches between position:fixed and position:absolute. Let the user decide.
6. Just remove the box-shadow, but keep jerky scrolling in opera (and possible other browsers?)
7. Do nothing, and keep the current jerky scrolling.

EDIT 16/12: Added a seventh option, and more elaboration on my testcase.

1) I think that having the toolbar fixed provides a massive boost to productivity and loosing that would be a real shame, though if we can't fix the issue in some other way, I would say this is not a bad fallback plan.

2) If this were done properly it could work, though I do think that a large proportion of people would dislike it, and others would outright hate it.

3) I tested this locally, and it provides no improvement as far as I could tell. The delay in the time from actually scrolling, to the jQuery scroll event being fired makes the problem visually just as bad - possibly even worse.

4) This is the only thing that I think could actually solve the problem properly, though I think it would be a massive task to get it right.

5) Yes, maybe... and/or a switch to toggle the 'auto hide' effect described in 2) for those that want it.

6) In my opinion the box shadow has to go regardless, scrolling is too slow with it and if the trade off is between usability and eye-candy, usability wins hands down.

7) Please, no!

See: http://s75582.gridserver.com/Ls - This guy seems to have it working perfectly.

http://stackoverflow.com/questions/1303729/iframe-100-height-inside-body...

Not quite sure how that would be implemented in our setup... but it brings hope (or maybe I don't understand enough about the current implementation to see how the two things are completely different?!). As far as I can tell, he has a fixed toolbar, with a scrolling iframe under it, or rather below it. I think that there is our problem... Our iframe is underneath the toolbar rather than below it. Put the iframe/overlay directly below the toolbar and problem solved.

mrfelton: that actually looks horrible in IE, try it, 2 scrollbars. Allthough that can be worked around (overflow:hidden on the body element), it can't be added into drupal easily because there aren't enough wrappers available, and things like the overlay append right after the body. It is possible, but it would be a pretty involving patch.

@Kiphaas7: Didn't check in IE, but in Firefox it's perfect. I never said I thought it would be easy!

What's status of this?

As far as I can tell, this is still a major issue and desperately needs to be addressed, somehow.

It seems to be fixed :s, at least I can't reproduce this...

@aspilicious: What browser/os ? I still have the issue in Firefox 3.5/Ubuntu.

@mrfleton...

Windows, works in every browsers.
I'm prety sure crappy ubuntu graphic driver is causing this.

Graphic supprt for ATI cards in ubuntu is almost zero.
And nvidea cards can be a trouble to...

Nah, this did not get magically fixed. Even so, one can't ignore linux (totally :P).

Since we're kinda stuck now:

Thinking about this a bit, I'm wondering if this bug report is actually a bigger issue in disguise.... I could type out a really long winded story bit it would only come down to this:

Drupal admin pages are, usually, too long.

The very same issue has been fixed for node create/edit pages with vertical tabs. I'm wondering if having some sort of informal height restriction on admin pages would result in better usability. I remember (not so fondly) the days where I first met the drupal 6 admin backend, and scrolled down a (really, really) long page, only to find out that the option wasn't there. While scrolling back up, I completely forgot where I was.

Smaller admin pages would in my opinion lead to:

• Inmediately seeing what the full content of the page is
• less options on a page (is a plus in my book)
• more tabs to click to reach the same content. (a negative, but how big of negative depends on how it's implemented).

(This post IS related to this issue; not having to scroll at all, or just a little, would circumvent this problem.)

Thoughts? Or am I rambling here?

hmm, I wouldn't say avoiding the problem fixes it, sorta like staying indoors doesn't make u immune to the flu :P

You'll have to get the flu first, before your body can actually decide if it needs to get sick. If staying inside means not getting in contact with the flu, you'll never get sick.

Err, but comparisons like these are quite silly :P.

The point I'm making in #31 (apart from the iframe graphical tearing issues) probably needs to be in a separate issue...

#31 is a bad solution, no issue needed for that ;).

Stupid thing is that I can't reproduce this issue, cause i don't have linux installed on my notebook.
Hmmm...

It's related to fixed positioned elements and iframes in certain browsers. So the glitch is definitely still there. I remember getting it also in some windows browsers, with fast scrolling.

----

@bad solution: so vertical tabs was a bad idea as well? :)

@35 nop kiphaas, avoiding the problem was the bad idea ;).

If the vertical tabs make live easier in admin that would be awsome, the admin screen is always been a pain in drupal, but D7 is a big improvement.
But thats maybe for D8 ;)

Well, as far as I know, there is no solution for having fixed items scrolling fast over iframes; other than avoiding the combination iframes + fast scrolling + fixed elements, for now it can only be fixed by browser makers.

Yes, admin in drupal 7 has been greatly improved, but the long, loong pages still exist, and that was the only point I was making. Also, overlay would be more usable with shorter pages.

But yea, drupal 8...

I'm prety sure that the only way to fix it is as I suggested in #22 (http://drupal.org/node/615204#comment-2380308). Don't left the iframe go behind the fixed content, but instead make the iframe stop shot of the fixed content so that is is just below it, not under it.

in ur example, the iframe container doesn't scroll, but the scrolling is the iframe itself. It doesn't seem very feasible to do this in a global way without introducing more problems than we solve and making the whole page content a frame seems like a regression to 1995

Actually, it would be a good solution (for the overlay, it wouldn't fix WYSIWYG iframe tearing). It would solve all kinds of scrolling issues with the overlay like anchor links and sticky tables.

However, it would introduce new problems, like hiding the window scrollbar crossbrowser, centering the content inside the iframe, setting the width at 88% inside the iframe, the closebutton would either need to be inside the iframe, or overlaying.... Etc, it would be a big patch to write for overlay. Both casey and myself both tried it once, but quit early due to above problems. Allthough, speaking for myself, I did not try too long.

It is possible, but difficult.

We have a working patch in #668640: Overlay shouldn't be based on jQuery UI Dialog and need reviewers.

#668640: Overlay shouldn't be based on jQuery UI Dialog landed and probably (99% sure) fixed by this. Feel free to reopen if you still have problems.