Bug 134786 – Web Inspector: Debugger Continue button is incorrectly sized

• Component: Web Inspector
• Status: RESOLVED FIXED

[Joseph Pecoraro]

Created attachment 234674 [details]
[IMAGE] Issue

* STEPS TO REPRODUCE
1. Inspect <http://bogojoker.com/shell/>
2. Set a breakpoint at easySlider.js:56:21
3. Click down arrow on page to trigger breakpoint
  => Debugger Continue button looks sized incorrect

Is this because the Dashboard View (LCD) has the debugger continue button? Do they generate a shared image with different sizes?

* NOTES
- This is a CSS canvas image with an explicit background size.
.navigation-bar .item.debugger-pause-resume.toggle.button > .glyph {
    background-image: -webkit-canvas(navigation-item-debugger-pause-resume-normal);
    background-size: 16px 16px;
}

[Radar WebKit Bug Importer]

<rdar://problem/17616947>

[Joseph Pecoraro]

So, I still have no clue why this happens.

But I have a better idea of how it happens. I made the debugger controls resume button regenerate every second and played with the inspector.

If the Web Inspector is wide enough to show the full DebuggerDashboardView, and if that full dashboard view is on a call frame with a very large name (like "(anonymous function) - easySlider.min.js)) causing the resume button in the DashboardView to be bad, then when the debugger controls resume button will regenerate incorrectly sized.

If the Web Inspector is narrow, and it gets the narrow DebuggerDashboardView, we will always have a correctly sized button in both places.

So the issue seems to be, when the dashboard view has really long text and has a poor layout, that somehow leaks out and affects the -webkit-canvas in the sidebar.

I can work around this, but there will probably still be an issue in WebCore that will need to be addressed.

[Joseph Pecoraro]

Created attachment 234736 [details]
[PATCH] Proposed Fix

This addresses numerous issues in the DebuggerDashboardView while at the same time magically fixing the pause button in the sidebar.

That will still need to be tracked down and addressed, it is clearly a crazy issue.

[Build Bot]

Comment on attachment 234736 [details]
[PATCH] Proposed Fix

Attachment 234736 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5288481622327296

New failing tests:
media/W3C/video/src/src_reflects_attribute_not_source_elements.html

[Build Bot]

Created attachment 234741 [details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[WebKit Commit Bot]

Comment on attachment 234736 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 234736

Committed r170991: <http://trac.webkit.org/changeset/170991>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.