[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