Bug 35216 – Web Inspector: REGRESSION: hangs when scrolling in Resource pane

• Component: Web Inspector (Deprecated)
• Status: RESOLVED INVALID

[Jeff Johnson]

Created attachment 49163 [details]
Samples of Safari

Overview:
There is a performance regression in the Resources pane of the Web Inspector from stock Safari 4.0.4 (6531.21.10) on Mac OS X 10.6.2 to WebKit TOT (r55052). Scrolling in the source of a large javascript file, for example, is very slow and can cause the Web Inspector and Safari to hang.

Steps to Reproduce:
1) Launch Terminal
2) WebKit/WebKitTools/Scripts/run-safari
3) Open http://www.youtube.com/watch?v=jqxENMKaeCU
4) Show Web Inspector
5) Select Resources pane
6) Enable resource tracking for this session, if not enabled
7) Select www-core-new-vfl147421.js in the resources list
8) Scroll up and down in the js source

Actual Results:
Scrolling is instantaneous.

Expected Results:
Scrolling is slow and causes Safari to hang and pinwheel.

Build Date & Platform:
WebKit svn r55052 built from source, Debug configuration, Mac OS X 10.6.2 Build 10C540, Xcode 3.2.1

Additional Information:
What seems to be happening is that the web inspector is continuously performing syntax highlighting. It syntax highlights the section at the top, then when I scroll down the text is all black, it syntax highlights, but when I scroll back to the top, the formerly highlighted text is now all black again, and then it gets syntax highlighted again.

This problem occurs whether or not I have ClickToFlash installed, so it has nothing to do with whether there is actually a Flash movie playing on the web page.

Attached are two samples of Safari, archived in the file "InspectorSamples.zip".

[Pavel Feldman]

Could it be that you are comparing Debug ToT to Release 4.0.4?

[Jeff Johnson]

That's correct. I just tried nightly build r55140, and it doesn't pinwheel, though it can be a bit jerky. Thus, as far as Debug builds are concerned, I can't really say how much of a regression there has been. I don't think the Safari 4.0.4 version has been tagged in svn.

As you mentioned in #webkit, this may be a problem with parsing very long lines of javascript. The code was changed to parse files continuously rather than just once, so some regression was expected, but I hope you agree that Debug builds should still remain usable, especially for this purpose, which is javascript debugging.

Let me know if you want me to perform further testing.

On a side note, is there a reason that line-wrapping is no longer used in the Resources pane? Without line-wrapping, it's harder to read js files with long lines.

[Pavel Feldman]

Created attachment 49635 [details]
[PATCH] Proposed fix.

[Pavel Feldman]

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/inspector/front-end/TextEditorHighlighter.js
Committed r55352

[Jeff Johnson]

The hanging actually seems a little worse on r55353 than it did on r55052.

Attaching a new sample.

[Jeff Johnson]

Created attachment 49684 [details]
Sample of Safari svn r55353

[Pavel Feldman]

(In reply to comment #6)
> Created an attachment (id=49684) [details]
> Sample of Safari svn r55353

Couple of observations:
1) Resource panel is now getting constant updates on the youtube's videoplayback resource. It repaints resource panel even when resource is being viewed. Should be easy to fix
2) I can see that on 4.0.4 scrolling also prevents movie from playing smoothly. It is not as bad as on ToT though.
3) As in sample attached, timeline shows me that most of the time is spent recalculating the styles. We just need to optimize our styles a lot and remove complex rules from them.

[WebKit Commit Bot]

Comment on attachment 49635 [details]
[PATCH] Proposed fix.

Cleared Timothy Hatcher's review+ from obsolete attachment 49635 [details] so that this bug does not appear in http://webkit.org/pending-commit.

[Rob Colburn]

This is ticket is marked REOPENED, but should be marked CLOSED/FIXED.
See:
Comment #8 From WebKit Commit Bot 2010-03-05 14:03:56 PST

[Jeff Johnson]

(In reply to comment #9)
> This is ticket is marked REOPENED, but should be marked CLOSED/FIXED.
> See:
> Comment #8 From WebKit Commit Bot 2010-03-05 14:03:56 PST

Why should it be marked closed/fixed? It was not in fact fixed.

[Rob Colburn]

Apologies, that statement was a bit strong.

I ran the test case you provided on all of the WebKits I have installed (including OS 10.6.2/Safari 5.1.5) and did not notice degraded performance while scrolling.

I had hoped that, given the age of the bug, it had been resolved somewhere else.

Thanks for verifying that the issue is still occurring.

[Jeff Johnson]

(In reply to comment #11)
> Apologies, that statement was a bit strong.
> 
> I ran the test case you provided on all of the WebKits I have installed (including OS 10.6.2/Safari 5.1.5) and did not notice degraded performance while scrolling.
> 
> I had hoped that, given the age of the bug, it had been resolved somewhere else.
> 
> Thanks for verifying that the issue is still occurring.

Ah. I didn't verify that the issue is still occurring. You only mentioned the old commit bot comment, which didn't seem to give a reason for closing the bug.

If you've tested it and can no longer reproduce, then it may have been fixed. It should be noted, though, that this was mainly an issue in Debug builds rather than Release builds.