57055 - [FIX]Expanded listboxes in forms don't retract/redraw on tab

Status: VERIFIED WORKSFORME

(Core :: Layout: Form Controls, defect, P2)

Description

[lchiang]

Transferred from bugscape http://bugscape.netscape.com/show_bug.cgi?id=2111.  
See bugscape bug for URL to use.

---- contents of bug report ----
1.  Click on the listbox labelled, "What type of food do you prefer?"
2.  Highlight one of the selections, but do not 'choose' it.
3.  While the listbox is still open, hit tab several times until the page begins 
to scroll. You'll note that the list box stays in one place on the screen, 
despite the movement of the rest of the page.  While this does not appear to be 
a major issue, it's causing video issues on the hardware device (see paw to use 
this).  Specifically, it's intermittently leaving a large chunk of video on the 
screen that does not get updated, regardless of what is opened or moved. I 
suspect there is a GTK issue as well.  However, the missing redraw in Mozilla is 
causing this GTK bug to come to the surface.  Furthermore, these video issues, 
while they normally appear to go away when the client is closed on a desktop 
machine -- there is no 'easy' way for the user to close his/her hardware client.  
Meanwhile this video glitch blocks access to any buttons, links, or any other 
trigger that it obscures, in addition to being an annoyance to user. I will try 
to attach screenshots of this bug 'in action'.
Corey Welton([e-mail])

------- Additional Comments From Jud Valeski 2000-10-12 17:26 -------
over to hyatt for investigation.

------- Additional Comments From Peter Trudelle 2000-10-16 12:56 -------
HTML Form Controls, ->rods

Comment 1

[rods (gone)]

Method DealWithPopups needs to check for a WM_KEYDOWN and a wParm of VK_TAB and 
then rollup. Other than that there isn't anyway to know that tabbing around may 
cause a scroll. This will ned to be done for each platform.

Comment 2

[rods (gone)]

Here is most of the fix:

BOOL
nsWindow :: DealWithPopups ( UINT inMsg, WPARAM wParam, LRESULT* outResult )
{
  if ( gRollupListener && gRollupWidget) {
    if (inMsg == WM_KEYDOWN && wParam == VK_TAB) {
      gRollupListener->Rollup();
      *outResult = TRUE;
      return TRUE;
    }

Comment 3

[David Hyatt]

This is probably good enough for now, but eventually I think we may not want to 
roll up the popup in all cases... .e.g., with arbitrary XUL popups there may be 
widgets inside the popup that you can tab among (see cmanske's color picker 
popup with a textfield inside).

Comment 4

[rods (gone)]

I agree, I think maybe we need to ask the roll listener is it wants to rollup in 
certain cases. today we have a simple method "ShouldRollupOnMouseWheelEvent" may 
we need to add additional methods like this one. For example, 
"ShouldRollupOnKeyEvent" and then pass in the keycodes or something like that.

Comment 5

[Vladimir Ermakov]

QA Contact Update

Comment 6

[rods (gone)]

The combobox rolls up now when tab is hit - marking works for me

Comment 7

[Vladimir Ermakov]

Verifying worksforme on build 2001-04-25-15-trunk linux redhat 6.2