Closed
Bug 5551
Opened 25 years ago
Closed 25 years ago
[PP][NATIVE-WIDGETS] List boxes: vertical scrollbar doesn't work
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
WONTFIX
M15
People
(Reporter: pierre, Assigned: pierre)
References
()
Details
- go to a page that displays some listboxes (like http://bugzilla.mozilla.org/
query.cgi)
- click on a vertical scrollbar arrows to scroll the list
==> nothing happens
Notes:
It's a weird bug. In nsListBox::DispatchMouseEvent(), if we use LClick(), the
scrollbar never works but if we use TrackControl(), it works from time to time.
Go figure... Of course, we have to make LClick() work because TrackControl()
doesn't allow to pass the 'modifiers' and do some multi-selection in the list.
Assigned to myself.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Summary: [PP] List boxes: vertical scrollbar doesn't work → [PP][NATIVE-WIDGETS] List boxes: vertical scrollbar doesn't work
Target Milestone: M9
Assignee | ||
Comment 3•25 years ago
|
||
Moving to M15 all the bugs that have a dependancy on GFX widgets and/or Ender.
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze. Widget Set component will be retired
shortly.
Comment 6•25 years ago
|
||
patrick, didn't you fix this?
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 7•25 years ago
|
||
This bug was reported against native widgets.
Resolved as WontFix because the final product will use gfx widgets.
(Answering for Patrick to the question above: no, it's not fixed yet)
Comment 8•25 years ago
|
||
Instead of marking this as "resolved wontfix", why not mark it as depending on
a "bug" to use gfx widgets instead of native widgets for that control? That
sounds a lot better than "won't fix" and shows up on the default query (new,
reopened, assigned).
Assignee | ||
Comment 9•25 years ago
|
||
It's precisely the reason why these bugs have been closed: we don't want them to
appear in the default queries. Handling a large bug list (>100 bugs) makes a
programmer's life miserable and we don't want to keep things that will not be
fixed. Some people suggested that we should have marked them Later instead of
WontFix. Maybe... But it's done and it's not worth spamming everybody by
reopening the bugs and closing them under a different denomination. Native
widgets are dead. The code is being removed.
Comment 10•25 years ago
|
||
Well.. the problem with just closing these bugs is that they don't show up on
default queries, which can cause newer bug reporters to miss the bug and submit
duplicates.
I think I'm seeing it from the bug hunter/reporter's point of view (unfixed
bugs should show up) while you're seeing it from the bug fixer's point of view
(bugs that won't be fixed as originally stated should not show up). There is
the [native-widgets] thing in the summary, and the nobody@* trick, but I still
understand the problem of this type of bug cluttering lists.
Assignee | ||
Comment 11•25 years ago
|
||
Still, we don't even want these to get into the way of anybody - coders or QA -
because native widgets are gone. They have been removed several months ago and
nobody reports duplicates anymore.
However you are right for other kinds of bugs that have been marked Later or
WontFix instead of going to nobody@mozilla.org. Note that the 'nobody' trick is
recent (about 2 months) and many latered bugs were marked so before the trick
existed.
You need to log in
before you can comment on or make changes to this bug.
Description
•