Sample app intended for deployment on Jboss 4.2

After I researched the historical reasons why the focus is reset when scrolling I came to the conclusion that the code I no longer necessary.

Mandeep Hayher added a comment - 04/Feb/09 03:55 PM
Tooltip for provinces in component-showcase sample app still seems to have positioning problem. If the target tooltip doesnot fit below the province name in current window size, the window scroll bar is forced to move and tooltip disappears while this scrolling happens.

Yip Ng added a comment - 09/Feb/09 02:23 PM ...it seems that the problem occurs only in Firefox, not in IE.

Yip Ng added a comment - 10/Feb/09 11:48 AM
Finally found what caused the problem. It was caused by the fix for ICE-3720. If we revert changes for ICE-3720, everything will work fine. See the attached screenshots.

So, it looks like we have a regression related to the removal of this focus mgmt. code.

Can you make the focus setting browser specific, as it seems to cause problems for IE to have it there, but causes problems in FF if it's not there.

I would prefer not to do that. Because we avoided in the past to have browser specific code, it paid off every time ICEfaces had to run on a new browser or browser version. I am not convinced that putting back the removed code is the only (or preferred) solution for fixing a component problem.

The removal of this focus code may also be involved with a focus issue in IE, as per ICE-4069.

I discovered that the difference in behavior between IE and Firefox is due to our focus preservation mechanism coupled with the difference in behavior of IE compared to Firefox.
Every time a submit is done the bridge sends the ID of the focused element to the browser. When the server sends back the updates it will append a command that will force the bridge to re-apply the focus back on the submitting element, just in case the focus gets lost due to a larger update.
In the case of component-showcase's tooltip panel the focus is re-applied on the "Tooltip Panel" command link found in the navigation panels. Because the command link is down at the bottom of the page Firefox will scroll to that focused command link (IE does not scroll to the focused element).
The onscroll event handler wired previously used to set the focus on the window and also cancel the sending of the focused element. This was a brute force solution to solve the limitations of our focus preservation mechanism.
Even if we would wire back the onscroll event handler if the "Tooltip Panel" command link would be vertically at the same level with the tooltip panel, thus not having to scroll down to the command link, we would still see this issue occurring.

An easy way to test my findings is to click on the window after clicking "Tooltip Panel" link. This will remove the focus from the link and make the tooltips show up correctly the first time.

May be some interactions in IE between these issues, should be reviewed together to ensure any changes will turn out positively for the related issues, etc.

Resolved by the fixes for ICE-4102.