Closed Bug 27661 Opened 25 years ago Closed 24 years ago

[GFX LIST]navigating in combo/list box causes entire page to scroll

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mik, Assigned: rods)

References

(Depends on 1 open bug)

Details

From Bug Helper: User-Agent: Mozilla/5.0 [ru-RU.KOI8-R] (Linux; I) BuildID: 2000012520 clicking up/down in list/combobox make all the page go up and down (selection in the box moves correctly), i.e. keyboard events are not being discarded after focused contorol Reproducible: Always Steps to Reproduce: 1. open page with list/combo box 2. give focus to listbox 3. press up or down Actual Results: selection in the box moves one step in the right direction, but entire page moves as well. Expected Results: selection moves one step, page remains on it's position
Reassigning to Saari.
Assignee: karnaze → saari
Depends on 24645
Status: NEW → ASSIGNED
Depends on: 24645
Target Milestone: M15
*** Bug 24179 has been marked as a duplicate of this bug. ***
This has actually gotten worse. Now the selection in the listbox isn't changed at all with the arrow keys. The only thing that happens is that the page scrolls. Linux CVS build 2000-02-20.
Ok, I'll pull this back into M14 as it should probably be fixed in that time frame
Target Milestone: M15 → M14
*** Bug 28030 has been marked as a duplicate of this bug. ***
Just as bad on WinNT and still kicking in 2000-02-22-08-M14. Changing OS to ALL.
OS: Linux → All
Hey I just patched the XBL to do the right thing, and it still scrolls *unless* you tab navigate into the combo/list box. Then it works. It seems the combo/list boxes are not taking focus via the mouse.
FYI, I didn't checkin that XBL patch because this is not PDT+ I'm pretty sure the focus code is fine here, but I don't know why nsEventStateManager::PostHandleEvent of the mousedown isn't setting focus. I don't see any of the menthods we've hooked into getting called at all, so I'm going to guess that the default action is being prevented (which will prevent the setting of focus in ESM). I'm guessing that prevention happens in the mouse down handling code of these widgets, since tabbing to set focus works. reassigning to karnaze
Assignee: saari → karnaze
Status: ASSIGNED → NEW
Reassigning to Rod.
Assignee: karnaze → rods
*** Bug 29083 has been marked as a duplicate of this bug. ***
When I try to duplicate this bug, I get behavior that is different than described here. I'll describe for a pull down combo box, like the ones at the top of this page. When I pull down a list and give the list focus then scroll, the list element that is highlighted does not change at all but the page scrolls. What is different is that the list remains fixed in place on the screen while the rest of the page scrolls out from under it. This causes the list to become seperated from the place that you pull it down from. This might be similar to Bug 28022 which describes problems with something getting separated from something else with scrolling.
Yes, the drop-down list is detaching while the page scrolls; there is a testcase in bug 28030 for that. Retested with 2000-02-23-08-M14 on WinNT.
*** Bug 31014 has been marked as a duplicate of this bug. ***
*** Bug 32515 has been marked as a duplicate of this bug. ***
I am marking this as a GFX List box issue and test it once GFX Dropdowns are working.
Status: NEW → ASSIGNED
Summary: navigating in combo/list box causes entire page to scroll → [GFX LIST]navigating in combo/list box causes entire page to scroll
changing to M15
Target Milestone: M14 → M15
mass-move to M16
Target Milestone: M15 → M16
*** Bug 33201 has been marked as a duplicate of this bug. ***
From bug 33201, on Mac it seem that holding the [down] key pressed does not trigger this bug, while pressing [down] repeatedly does. Also, on Win32, the list no longer moves above its "docked" position upon pressing [up]. But baased on the latest comments from rods@netscape.com, I'm wondering if there is any point reporting details until the GFX LIST code is turned on. Rod?
*** Bug 37696 has been marked as a duplicate of this bug. ***
*** Bug 36699 has been marked as a duplicate of this bug. ***
*** Bug 37870 has been marked as a duplicate of this bug. ***
I think this is now fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 36286 has been marked as a duplicate of this bug. ***
Updating QA contact.
QA Contact: ckritzer → bsharma
rods: recent bugs might contradict you. If you have a new tracking bug, feel free to rearrange the depends however you like.
Depends on: 27771, 39855, 52359, 57961
No longer depends on: 24645
Keywords: mostfreq
shouldn't this be marked REOPENED, since the dependencies are obviously not fixed?
Please reopen this bug. It is not entirely fixed. Navigating using the arrow keys in a combo box works now, but navigating using the mouse wheel (linux build 2000110621) still causes the entire page to scroll.
Reopen, however the wheelmouse should probably be considered separately. [cc] bryner
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The wheelmouse issue is covered in bug 33733, please don't munge it in with this bug...
bryner - should this bug be open, or not? Gerv
guess not, based on the comments above...
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
verified on build 2001-08-07-80-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.