Bug 35966 - Web Inspector: GraphBar elements at the bottom of Timeline are not visible.
Summary: Web Inspector: GraphBar elements at the bottom of Timeline are not visible.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-10 04:11 PST by Ilya Tikhonovsky
Modified: 2010-03-15 13:04 PDT (History)
4 users (show)

See Also:


Attachments
[Patch] The fix for GraphBar's position. (1.95 KB, patch)
2010-03-10 04:13 PST, Ilya Tikhonovsky
timothy: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff
Old screen shot with incorrect position of GraphBars. (11.17 KB, image/png)
2010-03-10 04:18 PST, Ilya Tikhonovsky
no flags Details
[Patch] The same patch but rebaselined. The fix fir Graph Bar's position. (1.90 KB, patch)
2010-03-13 05:08 PST, Ilya Tikhonovsky
timothy: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ilya Tikhonovsky 2010-03-10 04:11:51 PST
In case of long recording interval the latest GraphBar elements are not visible at all if they are small.
Comment 1 Timothy Hatcher 2010-03-10 04:13:33 PST
Under the scrollbal?
Comment 2 Ilya Tikhonovsky 2010-03-10 04:13:56 PST
Created attachment 50389 [details]
[Patch] The fix for GraphBar's position.
Comment 3 Ilya Tikhonovsky 2010-03-10 04:18:51 PST
Created attachment 50391 [details]
Old screen shot with incorrect position of GraphBars.
Comment 4 Ilya Tikhonovsky 2010-03-10 04:24:54 PST
(In reply to comment #1)
> Under the scrollbal?

Yep. Usually the last elements were hidden by scroll bar.
But the real reason of that was misspositioning because we are using expandOffset which for collapsing groups of elements, minimum width of the bars and the bar border size.
Comment 5 WebKit Commit Bot 2010-03-11 17:46:32 PST
Comment on attachment 50389 [details]
[Patch] The fix for GraphBar's position.

Rejecting patch 50389 from commit-queue.

Failed to run "['/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', '--reviewer', 'Timothy Hatcher', '--force']" exit_code: 2
patching file WebCore/ChangeLog
patch: **** malformed patch at line 18:          Unreviewed build fix. Fix variable name change that somehow didn't

patching file WebCore/inspector/front-end/TimelinePanel.js
Hunk #1 succeeded at 570 (offset -2 lines).

Full output: http://webkit-commit-queue.appspot.com/results/602028
Comment 6 Ilya Tikhonovsky 2010-03-13 05:08:40 PST
Created attachment 50654 [details]
[Patch] The same patch but rebaselined. The fix fir Graph Bar's position.
Comment 7 WebKit Commit Bot 2010-03-13 13:28:38 PST
Comment on attachment 50654 [details]
[Patch] The same patch but rebaselined. The fix fir Graph Bar's position.

Rejecting patch 50654 from commit-queue.

Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--exit-after-n-failures=1', '--quiet']" exit_code: 1
Running build-dumprendertree
Compiling Java tests
make: Nothing to be done for `default'.
Running tests from /Users/eseidel/Projects/CommitQueue/LayoutTests
Testing 12482 test cases.
fast/loader/api-test-new-window-data-load-base-url.html -> failed

Exiting early after 1 failures. 7684 tests run.
128.69s total testing time

7683 test cases (99%) succeeded
1 test case (<1%) had incorrect layout
3 test cases (<1%) had stderr output

Full output: http://webkit-commit-queue.appspot.com/results/731012
Comment 8 Pavel Feldman 2010-03-15 06:02:39 PDT
Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/inspector/front-end/TimelinePanel.js
Committed r55991
Comment 9 Eric Seidel (no email) 2010-03-15 12:06:07 PDT
I'm guessing this was bug 35594.
Comment 10 Ilya Tikhonovsky 2010-03-15 13:02:53 PDT
This change-list just change absolute positions of bar elements in the Timeline view of Web Inspector when WebInspector is opened and Timeline is recorded.

I think fast/loader/api-test-new-window-data-load-base-url.html test just flaky.
This test passed successfully when the patch was landed manually.
Comment 11 Eric Seidel (no email) 2010-03-15 13:04:25 PDT
Yes.  Definitely appears to be flakey.  You should feel encouraged to file bugs and simply re-queue (by marking cq+ again) if/when the commit-queue ever hits a flakey test.