| Issue 161: | Some admin operations don't work with Chrome | |
| Back to list |
Reported by Ed Heyl <edheyl@google.com> on Mon May 04 11:16:51 PDT 2009 Source: JIRA GERRIT-161 Affected Version: 2.0.10 Environment: Windows Vista, Chrome 2.0.172.8 Go to Admin Projects: https://android-git.corp.google.com/g/Gerrit#admin,projects scroll down and try to edit "vendor/google" or any project. Note: it bounces you right back to the project list (can't edit project details)
Sep 24, 2009
#1
code-rev...@gtempaccount.com
Sep 24, 2009
Comment by Shawn Pearce <sop@google.com> on Mon May 04 11:39:06 PDT 2009 Actually, this isn't entirely a WebKit bug. Its a nasty combination of WebKit, GWT, and Gerrit's abuse of GWT's FocusPanel around a table. To be more fair, what's really going on is, WebKit lacks a good way to place a keyboard listener on an arbitrary DOM object. Firefox, MSIE and Opera I believe support this better. So, GWT tries to emulate the behavior by creating a hidden <input type="text"> positioned underneath the table, at 0,0 relative to the top of the table (so directly under the first cell). When a mouse click occurs in the table, GWT schedules a delayed event to place keyboard focus into this hidden input box. On click, that delayed event executes, and keyboard focus is restored into the field. Except that the field is off screen when clicking on say vendor/google (v is rather late in the page) so the browser tries to "help" by moving the page to make the hidden input field visible, since it now has keyboard focus. This is what causes the jump back to the top. Unfortunately, somewhere along the line, that mouse click got stolen by the table and its focus handling, and never translates into a mouse click on the line you clicked on. So the link never activates. I've seen a double click actually get delayed until after the focus transfer, so in the case of the side-by-side viewer, double clicking on a line late in the table (e.g. around line 500 of a file) caused the window to jump back to the top and *then* dispatch the double click event near where the mouse is now, possibly double clicking around line 20, instead of where you meant. GWT developers have asked the Google GWT team to fix this problem in Safari, but its a low-priority/we'll never fix it sort of problem. I tried to come up with a work around one day and just gave up. My best work around was to just disable focus panels on tables in WebKit based browsers. But I didn't remove it from all tables yet. :-(
Sep 24, 2009
Comment by Shawn Pearce <sop@google.com> on Fri May 08 20:46:39 PDT 2009 This GWT bug from 2007 covers the issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=1313 Its 2009, and still unfixed.
Sep 24, 2009
Comment by Shawn Pearce <sop@google.com> on Fri May 15 18:41:57 PDT 2009 Fixed by https://review.source.android.com/9923
Sep 24, 2009
Update by Shawn Pearce <sop@google.com> on Fri May 15 18:41:57 PDT 2009 Fixed in version 2.0.12.
Status:
Fixed
Sep 25, 2009
(No comment was entered for this change.)
Labels:
FixedIn-2.0.12
Oct 25, 2012
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |