New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: IceBox
Owner: ----
Closed: Aug 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

onclick event fires extremely slowly, regression from older versions

Reported by virajm...@gmail.com, Jun 2 2010

Issue description

Chrome Version       : 5.0.375.55
URLs (if applicable) : see attached file
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. Create a html page with some CSS and a table with 4000 rows, each with a 
div that has a bunch of css classes and has an onclick handler which shows 
an alert. See attached file for an example.
2. Click the row

What is the expected result?
The onclick handler is immediately invoked, resulting in the alert showing 
instantly

What happens instead?
There is a long, noticeable lag (~1.5 seconds for me) after the click and 
before the alert appears. Repro on Mac and PC (same build of Chrome).
This is likely a regression - previous versions of Chrome didn't exhibit 
this latency.

Please provide any additional information below. Attach a screenshot if
possible.
This severely limits the performance of our website which relies heavily on  
fast Javascript. Chrome is SIGNIFICANTLY slower than any other browser for 
this behavior.
The behavior seems linked to CSS - if the style section is commented out, 
the latency is gone. Obviously, the fact that every other browser handles 
this without a problem implies that removing the CSS isn't really a 
feasible option.
While you work on the fix, a workaround would be much appreciated.
 
test.zip
39.4 KB Download

Comment 1 by mega...@gmail.com, Jun 2 2010

The following style is responsible for the slowdown:

.no-select, .rowsSelectable {
-moz-user-select:none;
-khtml-user-select:none;
-webkit-user-select:none;
user-select:none;
}

As a workaround you can prevent the user from selecting text by hooking 
document.onselectstart and blocking the element (e.preventDefault(); or returning 
false, depending on the browser).  Of course this is only practical for blocking the 
entire document, although you can still selectively allow selections inside of 
<textarea> and text-type <input>s with some logic in your event handler.

This is the method we are using in our IE7 app here at work.  Works OK for us.
Thanks - that definitely seems to help. Even after removing that css though, response 
time in Chrome *feels* slower than IE/FF. I suspect there is something else going on 
here too, but removing that CSS does improve it to where it's workable.

Project Member

Comment 3 by bugdroid1@chromium.org, Aug 10 2012

Status: IceBox
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.
Project Member

Comment 4 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 5 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-Undefined

Sign in to add a comment