Bug 10550
Summary: | Pages With iframes Flash During Core Image Transitions | ||
---|---|---|---|
Product: | WebKit | Reporter: | Thaddeus Cooper <tcooper> |
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | mitz, simon.fraser |
Priority: | P2 | ||
Version: | 420+ | ||
Hardware: | Mac | ||
OS: | OS X 10.4 |
Thaddeus Cooper
Download the following sample code: http://developer.apple.com/samplecode/CarbonCocoaCoreImageTab/index.html. This shows two webviews in two different tabs. In one tab point it at http://www.apple.com/ (any URL will work) in the second tab point to http://www.nomoreboxes.com/wcstore/. Now select the first tab to go back to the Apple site. The transition works correctly. Select the second tab and you'll notice that there is a flash that shows all the visible iframes before the transition starts. This seems to be on the mouse up event. I am able to duplicate this problem in both the shipping version of Webkit and I have had a report (from mitz) it also occurs in the nightly.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
mitz
I think the problem reduces to the fact that WebHTMLView ends up painting its subviews into the window when it's sent a -cacheDisplayInRect:toBitmapImageRep: message. You can see this by creating a trivial browser in Interface Builder and adding a button that does something like
NSRect frame = [webView frame];
NSBitmapImageRep *rep = [webView bitmapImageRepForCachingDisplayInRect:frame];
[webView cacheDisplayInRect:frame toBitmapImageRep:rep];
Load http://www.nomoreboxes.com/wcstore/ into the WebView, turn on Quartz Debug flashing and click the button. You'll see the iframes being painted into the window.
I'm guessing that this has to do with WebHTMLView overriding private AppKit methods.
mitz
(In reply to comment #1)
> I'm guessing that this has to do with WebHTMLView overriding private AppKit
> methods.
I mean specifically private NSView drawing methods.
mitz
I wonder if <http://trac.webkit.org/changeset/35176> didn't fix this.