My favorites | Sign in
Project Home Downloads Wiki Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 1313: Focusable implementation breaks ScrollPanels in Safari
13 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Closed:  Jan 2010

Sign in to add a comment
Reported by, Jun 28, 2007
Found in GWT Release: 1.4 RC1

Detailed description: When using a FocusPanel or a CustomButton inside a ScrollPanel, the 
focusable element that is used in the Safari implementation is an absolutely positioned hidden 
textbox. Because it is positioned absolutely, the texbox is shown at the wrong place, below the 
scrollpanel. Therefore, when the FocusPanel or CustomButton receives the focus, the window 
scrolls to the invisible textbox instead of staying at the current position.

This is particularly annoying for all types of CustomButtons inside ScrollPanels: When you first 
click on the button, the window scrolls and the click is ignored. If the window scrolled so far that 
you can't see the button anymore on the screen, there is just no way to click on it.

Workaround if you have one: Change the Focusable implementation for the Safari binding to use 
an element not absolutely but relatively positioned.

Jun 28, 2007
Which version of Safari is this breaking on?
Status: NeedsInfo
Labels: -Priority-Medium Priority-Critical Category-UI Milestone-1_4_RC2
Jun 29, 2007
It was tested on both Safari 2.0.4 and the latest beta 3.0.2, on Mac OS X 10.4.10.

It's not a browser bug so it occurs in all versions, it's related to the fact that the element has an absolute position 
so it's logical that it displays at the wrong place for scrollable div blocks.
Jul 9, 2007
IMPORTANT: This bug has been noticed when using GWT with an HTML page in STRICT mode. The bug does not 
occur in QUIRKS mode. In strict mode, in does not occur in other browsers than Safari.
Jul 10, 2007
Well, I spoke too quickly: the same problem also occurs in quirks mode with a custom PushButton (of the 
simplest form). So please ignore my previous comment.

However the toggle Buttons that are used in the toolbar of the rich text editor (includeed in the kitchen sink 
application) seem to work correctly for some reason.
Jul 11, 2007
(No comment was entered for this change.)
Status: Accepted
Labels: -Priority-Critical Priority-Medium
Jul 23, 2007
(No comment was entered for this change.)
Labels: -Milestone-1_4_RC2
Sep 24, 2007
It seems that this one is fixed now. Thank you for your work.
Apr 9, 2008
(No comment was entered for this change.)
Status: Fixed
Dec 8, 2008
From Paul:
Here's a code snippet that shows the necessary parts to make the bug
happen....just run this in web mode on safari or chrome, scroll the
window down a bit, then click on one of the labels to see the window
scroll back to the top.

public class FooPanel extends DockPanel {

   public FooPanel() {
       VerticalPanel ap = new VerticalPanel();
       for (int i = 0; i < 50; i++) {
           ap.add(new Label(Integer.toString(i)));

       MyFocusPanel focus = new MyFocusPanel();

       super.add(new ScrollPanel(focus), DockPanel.CENTER);

// you can use the normal FocusPanel to show the bug....this just shows
it's the FocusImpl that's the problem
class MyFocusPanel extends SimplePanel {

 static final FocusImpl impl = FocusImpl.getFocusImplForPanel();

 public MyFocusPanel() {

Status: Accepted
Dec 17, 2008
We are only using priority high and critical now, so removing priority medium.
Labels: -Priority-Medium
Feb 17, 2009
I'm also having problems with this. Is there a workaround available?
May 6, 2009
I am having the same issue in the hosted browser in Linux. I have a FocusPanel inside
a ScrollPanel. If I scroll the panel down to the bottom, then click on the
FocusPanel, the ScrollPanel scrolls back up to the top left corner, and the MouseDown
event is not registered properly.
The problem does not occur if I open the same application in Firefox.
Jun 28, 2009
Exactly the same problem, with GWT 1.6 on Windows Vista. The problem appears in both
Google Chrome and Safari 4.0 (530.17). Is there at least a wok around for
this? I've tried adding a click handler to the FocusPanel to intercept the clicks and
then after processing them stop from being propagated. But this indeed did not work
at all because somehow the click event does not reach the focus panel.

Now, I am just curious... It's been 2 (!!!!) years since the problem was reported why
does no any one do anything about it?!
Jul 3, 2009
Project Member #14 t.broyer
If you don't intend in supporting Safari 3, you can just switch to using FocusImpl for 
user.agent=safari permutations (in place of FocusImplSafari).
See (try 
the test page –link at the bottom of the article– in Chrome and Safari)
I don't know about iPhone/Android support though...
Jan 13, 2010
committed as r7390

We now use a focusable div instead of an input element, which seems to fix the 
problem.  There is still an input element to support accessKeys, but this should 
affect very few users. 
Status: FixedNotReleased
Labels: Milestone-2_0_1
Feb 4, 2010
Is there a fix for GWT 1.7?  It will be a while before we can move up to GWT 2.0.
Feb 4, 2010
(No comment was entered for this change.)
Status: Fixed
Sign in to add a comment

Powered by Google Project Hosting