[Webkit-unassigned] [Bug 33150] Do not render the full frame when there is some elements with fixed positioning

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33150


Shinichiro Hamaji <hamaji at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hamaji at chromium.org




--- Comment #87 from Shinichiro Hamaji <hamaji at chromium.org>  2010-03-29 01:15:00 PST ---
It seemed r55890 caused a regression at least for Qt and Chromium (I guess this
issue will happen all environments where platformWidget() == NULL). I confirmed
reverting r55890 fixes the issue.

How to reproduce:

- Run Chromium or QtLauncher
- Download
http://chromium.googlecode.com/issues/attachment?aid=8184776065656844667&name=testcase.xht
and open it with your browser
- You would notice the image will be wrongly rendered when you scroll

I didn't understand the patch yet, but it seems we are using the fast path when
we cannot use it.

Related Chromium bugs: http://crbug.com/39075 http://crbug.com/39394

By the way, I couldn't understand two changes in the patch. They might not be
related to this issue though.

1. Comment 45 said we won't change the behavior when platformWidget is
non-NULL, but the change for useSlowRepaints() seems to be changing the
behavior.

2. I wasn't sure why we call invalidateContentsAndWindow() instead of scroll()
when fast scroll fails (this should not be related the issue I'm reporting
because scrollContentsFastPath returns true with the testcase).

> -       // FIXME: Find a way to scroll subframes with this faster path
> -       hostWindow()->scroll(-scrollDelta, scrollViewRect, clipRect);
> +        // FIXME: Find a way to scroll subframes with this faster path
> +        if (!scrollContentsFastPath(-scrollDelta, scrollViewRect, clipRect))
> +            hostWindow()->invalidateContentsForSlowScroll(updateRect, false);

Again, I didn't understand the patch well, I'm sorry if my uneducated guesses
were completely pointless.

Benjamin, could you look into this? If it will take a few days to fix this
issue, I'd like to revert this patch for now (and hopefully a refined patch
will be landed with thorough tests).

Thanks,

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.