Bug 32940 - [GTK] Progress notification update taking longer
Summary: [GTK] Progress notification update taking longer
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-25 13:27 PST by Estêvão Samuel Procópio Amaral
Modified: 2009-12-28 08:49 PST (History)
5 users (show)

See Also:


Attachments
Changing the download throttle conditions (1.89 KB, patch)
2009-12-25 15:23 PST, Estêvão Samuel Procópio Amaral
no flags Details | Formatted Diff | Diff
New version of throttle conditions (2.88 KB, patch)
2009-12-25 16:20 PST, Estêvão Samuel Procópio Amaral
gns: review-
Details | Formatted Diff | Diff
Conforming with comment #5 (2.71 KB, patch)
2009-12-25 17:04 PST, Estêvão Samuel Procópio Amaral
gns: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff
patch with right ChangeLog (2.71 KB, patch)
2009-12-27 19:12 PST, Estêvão Samuel Procópio Amaral
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Estêvão Samuel Procópio Amaral 2009-12-25 13:27:38 PST
The progress notification in WebKit GTK implementation is throttled in order to consume less CPU. Although it's not updating properly. Sometimes it takes a long time to show statuses updates (only working after passing 3% of the download). To some file sizes it's a pain not to know if the download is properly occuring.
Comment 1 Estêvão Samuel Procópio Amaral 2009-12-25 15:23:06 PST
Created attachment 45500 [details]
Changing the download throttle conditions

This patch is a proposal for changing the download notification throttle.

The changes are quite simple: 
The code only updates lastElapsed when a progress notification occurs. If we passed the lastElapsed by more then 0.7 secs from now, we notify again.
I added another static variable, lastNotifiedProgress, that holds the value of the last notified progress. If we passed more than 1% of the last notified progress, we notify again.

I must state that this patch is not the final one. I think it's important that some of you guys try this patch to see if it's good or if we need to think a better way to do this throttle.
Comment 2 WebKit Review Bot 2009-12-25 15:27:53 PST
Attachment 45500 [details] did not pass style-queue:

Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebKit/gtk/webkit/webkitdownload.cpp:867:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
WebKit/gtk/webkit/webkitdownload.cpp:868:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Total errors found: 2
Comment 3 Estêvão Samuel Procópio Amaral 2009-12-25 16:20:50 PST
Created attachment 45501 [details]
New version of throttle conditions

Another version of the patch respecting the coding conventions and calling less functions
Comment 4 WebKit Review Bot 2009-12-25 16:23:35 PST
style-queue ran check-webkit-style on attachment 45501 [details] without any errors.
Comment 5 Gustavo Noronha (kov) 2009-12-25 16:50:57 PST
Comment on attachment 45501 [details]
New version of throttle conditions

ok, two more things - I would preffer if you said in the ChangeLog why you are doing the change (i.e., to fix the notification being bumpy), and second, the && operators should be at the end of the previous line, not at the beggining of the next line (I wrote it wrongly at first ;D). THanks.
Comment 6 Gustavo Noronha (kov) 2009-12-25 16:51:53 PST
(In reply to comment #5)
> (From update of attachment 45501 [details])
> ok, two more things - I would preffer if you said in the ChangeLog why you are
> doing the change (i.e., to fix the notification being bumpy), and second, the
> && operators should be at the end of the previous line, not at the beggining of
> the next line (I wrote it wrongly at first ;D). THanks.

ok, ignore the && one /me hits his head on the keyboard
Comment 7 Estêvão Samuel Procópio Amaral 2009-12-25 17:04:57 PST
Created attachment 45503 [details]
Conforming with comment #5
Comment 8 WebKit Commit Bot 2009-12-27 01:03:49 PST
Comment on attachment 45503 [details]
Conforming with comment #5

Rejecting patch 45503 from commit-queue.

Unexpected failure when landing patch!  Please file a bug against bugzilla-tool.
Failed to run "['WebKitTools/Scripts/bugzilla-tool', '--status-host=webkit-commit-queue.appspot.com', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', '--quiet', '45503']" exit_code: 1
Last 500 characters of output:
)
  File "/Users/eseidel/Projects/CommitQueueSVN/WebKitTools/Scripts/modules/statusbot.py", line 73, in update_status
    response = self.browser.submit()
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 547, in submit
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 209, in open
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 261, in _mech_open
mechanize._response.httperror_seek_wrapper: HTTP Error 500: Internal Server Error
Comment 9 Gustavo Noronha (kov) 2009-12-27 11:10:46 PST
Comment on attachment 45503 [details]
Conforming with comment #5

Let's see if that was a temporary problem.
Comment 10 WebKit Commit Bot 2009-12-27 11:24:38 PST
Comment on attachment 45503 [details]
Conforming with comment #5

Rejecting patch 45503 from commit-queue.

Unexpected failure when landing patch!  Please file a bug against bugzilla-tool.
Failed to run "['WebKitTools/Scripts/bugzilla-tool', '--status-host=webkit-commit-queue.appspot.com', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', '--quiet', '45503']" exit_code: 1
Last 500 characters of output:
)
  File "/Users/eseidel/Projects/CommitQueueSVN/WebKitTools/Scripts/modules/statusbot.py", line 73, in update_status
    response = self.browser.submit()
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 547, in submit
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 209, in open
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 261, in _mech_open
mechanize._response.httperror_seek_wrapper: HTTP Error 500: Internal Server Error
Comment 11 Adam Barth 2009-12-27 18:12:02 PST
Eric, this is a strange commit-queue message
Comment 12 Eric Seidel (no email) 2009-12-27 18:17:51 PST
Comment on attachment 45503 [details]
Conforming with comment #5

This is just app engine giving us 500 errors as it does.  We should be catching these, but I expect this is a temporary error.  I'll file a bug about it.
Comment 13 Eric Seidel (no email) 2009-12-27 18:21:11 PST
Filed bug 32976 about handling the 500 errors better.
Comment 14 WebKit Commit Bot 2009-12-27 18:31:00 PST
Comment on attachment 45503 [details]
Conforming with comment #5

Rejecting patch 45503 from commit-queue.

Unexpected failure when landing patch!  Please file a bug against bugzilla-tool.
Failed to run "['WebKitTools/Scripts/bugzilla-tool', '--status-host=webkit-commit-queue.appspot.com', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', '--quiet', '45503']" exit_code: 1
Last 500 characters of output:
)
  File "/Users/eseidel/Projects/CommitQueueSVN/WebKitTools/Scripts/modules/statusbot.py", line 73, in update_status
    response = self.browser.submit()
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 547, in submit
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 209, in open
  File "build/bdist.macosx-10.5-i386/egg/mechanize/_mechanize.py", line 261, in _mech_open
mechanize._response.httperror_seek_wrapper: HTTP Error 500: Internal Server Error
Comment 15 Eric Seidel (no email) 2009-12-27 18:38:25 PST
Adam suggests the commit-queue might be trying to post a huge log to the server, or that in some way the log it is posting is causing a failure.  I can look at the log on the server, sec.
Comment 16 Eric Seidel (no email) 2009-12-27 18:54:02 PST
The failure it's actually hitting is:
Failed to run "['svn', 'commit', '-m', '2009-12-27  Est\xc3\xaav\xc3\xa3o Samuel Proc\xc3\xb3pio  <tevaum@gmail.com>\n\n        Reviewed by noone (OOPS!).\n\n        Bug 32940: [GTK] Changing the download throttle conditions.\n        https://bugs.webkit.org/show_bug.cgi?id=32716\n\n        The WebKitDownload progress notification was taking long to\n        update. This fix makes notification happens each 0.7 secs\n        or when the progress ups in 1%.\n\n        * WebKit/gtk/webkit/webkitdownload.cpp:\n']" exit_code: 1

I suspect there may be an encoding issue.
Comment 17 Eric Seidel (no email) 2009-12-27 19:01:33 PST
Bug 26927 and bug 32343 are related to this type of failure.
Comment 18 Eric Seidel (no email) 2009-12-27 19:03:02 PST
I got my comments out of order, but here:

Oh.  Well, the ChangeLog has also been edited, so svn commit is likely rejecting it due to having OOPS! in the ChangeLog because it couldn't find "NOBODY(OOPS!)" to replace with the reviewer.

So the cq- is correct, this can't be landed via the commit queue.  There also might be encoding failures at play here, not sure.
Comment 19 Estêvão Samuel Procópio Amaral 2009-12-27 19:06:22 PST
(In reply to comment #18)
> So the cq- is correct, this can't be landed via the commit queue.  There also
> might be encoding failures at play here, not sure.

Well... I'll take a look at the changelog and encoding stuff and submit another patch.
I committed locally before running prepare-Changelog... That's why it's screwed. Sorry for the trouble... :]
Comment 20 Eric Seidel (no email) 2009-12-27 19:08:14 PST
The only problem with this patch that I can see is that you changed the "Reviewed by" line from the default prepare-ChangeLog template.  You replaced "NOBODY" with "noone".  Yes, it's lame that our scripts depend on that, but for now they do. :(

If you fix the NOBODY bit in the ChangeLog and re-submit a patch then the commit-queue should work just fine.
Comment 21 Estêvão Samuel Procópio Amaral 2009-12-27 19:12:19 PST
Created attachment 45540 [details]
patch with right ChangeLog
Comment 22 WebKit Review Bot 2009-12-27 19:13:44 PST
style-queue ran check-webkit-style on attachment 45540 [details] without any errors.
Comment 23 WebKit Commit Bot 2009-12-28 05:46:55 PST
Comment on attachment 45540 [details]
patch with right ChangeLog

Rejecting patch 45540 from commit-queue.

Unexpected failure when landing patch!  Please file a bug against bugzilla-tool.
Failed to run "['WebKitTools/Scripts/bugzilla-tool', '--status-host=webkit-commit-queue.appspot.com', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', '--quiet', '45540']" exit_code: 1
Last 500 characters of output:
134, in fetch_attachments_from_bug
    bug = self.fetch_bug(bug_id)
  File "/Users/eseidel/Projects/CommitQueueSVN/WebKitTools/Scripts/modules/bugzilla.py", line 130, in fetch_bug
    return self._parse_bug_page(page)
  File "/Users/eseidel/Projects/CommitQueueSVN/WebKitTools/Scripts/modules/bugzilla.py", line 123, in _parse_bug_page
    bug["attachments"] = [self._parse_attachment_element(element, bug_id) for element in soup.findAll('attachment')]
NameError: global name 'bug_id' is not defined
Comment 24 Adam Barth 2009-12-28 08:28:49 PST
The rejection is due to a regression Eric introduced last night.  The bug has been fixed but Eric might need to kick the commit-queue.
Comment 25 Eric Seidel (no email) 2009-12-28 08:35:50 PST
Comment on attachment 45540 [details]
patch with right ChangeLog

Sorry, I broke the commit-queue, but Adam fixed it in http://trac.webkit.org/changeset/52595.  Its working again now.  Apologies for the trouble.
Comment 26 WebKit Commit Bot 2009-12-28 08:49:05 PST
Comment on attachment 45540 [details]
patch with right ChangeLog

Clearing flags on attachment: 45540

Committed r52597: <http://trac.webkit.org/changeset/52597>
Comment 27 WebKit Commit Bot 2009-12-28 08:49:11 PST
All reviewed patches have been landed.  Closing bug.