[Webkit-unassigned] [Bug 51967] New: [chromium] Opening/closing inspector with compositor active causes assertion

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 5 16:10:05 PST 2011


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

           Summary: [chromium] Opening/closing inspector with compositor
                    active causes assertion
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: enne at google.com
                CC: kbr at google.com, jamesr at chromium.org,
                    vangelis at chromium.org, enne at google.com,
                    nduca at chromium.org


What steps will reproduce the problem?
1. Open a page that triggers the compositor (e.g. WebGL content)
2. Open the inspector.

Alternatively, open the inspector on a page that doesn't trigger the compositor, switch to a tab that does, then close the inspector.

The assertion is on the first line of RenderWidget::didInvalidateRect(), where it assumes that any invalidation is (0,0,1,1) if accelerated compositing is active, but WebDevToolsAgentImpl::hideHighlight damages the entire view.

As a side note, it looks like there are a number of other places in WebKit where didInvalidateRect is called without conditional guards (see WebViewImpl::resize or RenderWidget::didInvalidateRect for an example of where we do check.)  I'm not sure how any of those code sites have ever worked with compositing.  This logic really needs to be refactored so that this type of bug doesn't get introduced again in the future.

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



More information about the webkit-unassigned mailing list