14269 2007-06-20 23:48:47 -0700 REGRESSION: Gmail links stop working after computer sleep 2007-08-25 14:51:11 -0700 1 1 1 Unclassified WebKit Page Loading 523.x (Safari 3) Mac OS X 10.4 RESOLVED FIXED http://mail.google.com/mail HasReduction, InRadar, Regression P1 Normal --- 1 ruben webkit-unassigned andersca darin ddkilzer oldest_to_newest 6942 0 ruben 2007-06-20 23:48:47 -0700 The problem occurs when using Gmail and putting the Mac to sleep. After wakeup the Gmail page is not responsive, e.g., most links do not work anymore. After a delay of about 1 to 3 minutes the links start working again. A page reload does solve the problem, too. Steps to duplicate the problem: 1. Open http://mail.google.com/mail and login 2. While on the "Inbox" page: put your Mac to sleep 3. Wait a least 5 minutes (If you wait less, you cannot dup the problem). 4. Wakeup your Mac 5. Press the "Refresh" link or "Sent mail" link -> nothing happens 6. Wait about 1 to 2 minutes and the links work again I put "Regression" in the title, as the problem cannot be duplicated in Safari 2 (Tiger/419.x) . 6932 1 15154 ruben 2007-06-21 00:06:14 -0700 Created attachment 15154 WebCore/Timer.cpp patch to work around the problem 6935 2 ruben 2007-06-21 00:15:30 -0700 After some debugging I found the WebCore SharedTimer to be the problem. Normally, the SharedTimer is restarted when the time of the first Timer on the timerHeap changes. After a sleep however, the first Timer on the timerHeap has an absolute time that is in the past. The SharedTimer doesn't get updated when new Timers (for loading pages) are added as they never can become the first timer. My workaround (see attached patch) is to always update the SharedTimer, even when the timer is not the the first timer. I hope this makes sense :-). 6898 3 ddkilzer 2007-06-21 07:33:49 -0700 Updating bug since it's a regression. 6899 4 15154 ddkilzer 2007-06-21 07:40:30 -0700 Comment on attachment 15154 WebCore/Timer.cpp patch to work around the problem Thanks for the patch and the detective work, Ruben! NOTE: I'm not reviewing the correctness of the code changes in the patch, but instead the patch itself. 1. Please create a ChangeLog entry for this patch using WebKitTools/Scripts/prepare-ChangeLog. 2. Please use WebKitTools/Scripts/svn-create-patch to generate a patch of the ChangeLog entry and the code fix. 3. All changes need a layout test unless it's not possible to make one. (In this case, I'd say it's not possible to emulate sleeping for over 5 minutes in the layout tests, so just note this in the ChangeLog entry as well.) More details here: http://webkit.org/coding/contributing.html Please make the above corrections and attach a new patch. Please also set the "review?" flag on the patch so that reviewers will notice it. Thanks again! 6879 5 ddkilzer 2007-06-21 08:54:32 -0700 Confirmed with a local debug build of WebKit r23713 with Safari 3.0 (522.11) on Mac OS X 10.4.10 (8R218). Nice job spotting this bug and tracking down the cause and fix!! I noticed that the cursor in the Bugzilla "Additional Comments" text area doesn't blink during this period after wake, either! :) 6881 6 ruben 2007-06-21 09:09:49 -0700 Hi David, Thanks for confirming this bug! I will follow "the process" and attach a new patch shortly. 6816 7 ddkilzer 2007-06-21 17:13:29 -0700 <rdar://problem/5286444> 3356 8 andersca 2007-08-01 14:24:18 -0700 This might not be a good idea to do performance-wise as it would involve destroying and then creating a new CFRunLoopTimer each time a timer is added. Darin, is that acceptable or do you have a better idea? 3203 9 darin 2007-08-01 15:22:31 -0700 (In reply to comment #8) > Darin, is that acceptable or do you have a better idea? This doesn't fix the real problem. What it does is make scheduling a new timer "tickle" the shared timer and make it fire. There must be a better fix where we make the shared timer fire without scheduling a new timer. 3200 10 andersca 2007-08-01 18:03:40 -0700 We could add a new shared timer function that we'd always call when adding a timer. On the Mac, this would check if the fire date is in the past and then re-set the timer. This would rely on new timers always being added sooner or later though. 3088 11 andersca 2007-08-03 13:41:38 -0700 Committed revision 24851. 1468 12 ruben 2007-08-25 14:51:11 -0700 I wasn't able to duplicate the problem anymore. Thanks for fixing this bug! 15154 2007-06-21 00:06:14 -0700 2007-06-21 07:40:30 -0700 WebCore/Timer.cpp patch to work around the problem platform_Timer.diff text/plain 818 ruben SW5kZXg6IHBsYXRmb3JtL1RpbWVyLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBwbGF0Zm9ybS9UaW1lci5j cHAJKHJldmlzaW9uIDIzNTU5KQorKysgcGxhdGZvcm0vVGltZXIuY3BwCSh3b3JraW5nIGNvcHkp CkBAIC0yODQsOSArMjg0LDYgQEAKICAgICBkb3VibGUgb2xkVGltZSA9IG1fbmV4dEZpcmVUaW1l OwogICAgIGlmIChvbGRUaW1lICE9IG5ld1RpbWUpIHsKICAgICAgICAgbV9uZXh0RmlyZVRpbWUg PSBuZXdUaW1lOwotCi0gICAgICAgIGJvb2wgd2FzRmlyc3RUaW1lckluSGVhcCA9IG1faGVhcElu ZGV4ID09IDA7Ci0KICAgICAgICAgaWYgKG9sZFRpbWUgPT0gMCkKICAgICAgICAgICAgIGhlYXBJ bnNlcnQoKTsKICAgICAgICAgZWxzZSBpZiAobmV3VGltZSA9PSAwKQpAQCAtMjk2LDEzICsyOTMs MTEgQEAKICAgICAgICAgZWxzZQogICAgICAgICAgICAgaGVhcEluY3JlYXNlS2V5KCk7CiAKLSAg ICAgICAgYm9vbCBpc0ZpcnN0VGltZXJJbkhlYXAgPSBtX2hlYXBJbmRleCA9PSAwOwotCi0gICAg ICAgIGlmICh3YXNGaXJzdFRpbWVySW5IZWFwIHx8IGlzRmlyc3RUaW1lckluSGVhcCkKLSAgICAg ICAgICAgIHVwZGF0ZVNoYXJlZFRpbWVyKCk7CisgICAgICAgIHVwZGF0ZVNoYXJlZFRpbWVyKCk7 CiAgICAgfQogCiAgICAgY2hlY2tDb25zaXN0ZW5jeSgpOworICAgIAogfQogCiB2b2lkIFRpbWVy QmFzZTo6Y29sbGVjdEZpcmluZ1RpbWVycyhkb3VibGUgZmlyZVRpbWUsIFZlY3RvcjxUaW1lckJh c2UqPiYgZmlyaW5nVGltZXJzKQo=