Closed Bug 134889 Opened 23 years ago Closed 23 years ago

Last visible item in outliner cannot be selected if it is only partly visible

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: gary, Assigned: janv)

References

Details

(Keywords: regression, Whiteboard: [adt1])

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020401 BuildID: 2002040103 In any outliner I have tried in this build, if the row for the last visible item in the outliner is not fully visible (due to there being more content than there is space assigned to the outliner), then the last row cannot be selected with the mouse. It can still be navigated to with the keyboard. Same behaviour in preferences, address book, bookmark management etc. Reproducible: Always Steps to Reproduce: 1. Open the bookmark management window. 2. Resize the window so that the last item visible in the outliner is partly hidden. 3. Try to click the last visible item. Actual Results: The item cannot be selected by clicking unless the window is resized to show the whole row. Expected Results: The row should have been selected.
*** Bug 134885 has been marked as a duplicate of this bug. ***
This was working in 2002-03-28-08 and is broken in 2002-03-29-08 and thereafter (on Linux, at least). This is almost certainly a regression from the <tree>/<listbox>/<outliner> landing. This is also an issue with mailnews, the XP filepicker, etc.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0, nsbeta1, regression
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 135122 has been marked as a duplicate of this bug. ***
This bug has quite high visibility.
*** Bug 135492 has been marked as a duplicate of this bug. ***
*** Bug 135554 has been marked as a duplicate of this bug. ***
I don't know if this is the same bug or not, but I just ran into a case where I had to resize my thread pane to be able to scroll down to the last 2-3 messages. Dragging the thumb down didn't do anything.
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
*** Bug 135688 has been marked as a duplicate of this bug. ***
*** Bug 135646 has been marked as a duplicate of this bug. ***
*** Bug 135732 has been marked as a duplicate of this bug. ***
*** Bug 134636 has been marked as a duplicate of this bug. ***
*** Bug 134636 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0+
*** Bug 135950 has been marked as a duplicate of this bug. ***
I also can't cause the folder pane to scroll down by dragging a message near the bottom of the folder pane. I can make it scroll up while dragging. This is a regression since 3/14 and is probably the same bug.
as I keep hitting this more and more, I think this should be higher than an ADT3. For those of us who use the default sort where new messages show up on the bottom, this is pretty annoying.
This is gonna drown us in bug reports if we ship it in RC1.
Blocks: 134771
I concur with Scott and maintain that this should be higher than adt3. Submitting to the nav triage team for consideration.
CC'ing Jan in case he has a dupe or a patch for us.
raising to [adt1] on behalf of the ADT.
Whiteboard: [adt3] → [adt1]
The patch in bug 135048 should help.
taking
Assignee: hewitt → varga
Jan will this fix bug 120410 perhaps?
Should be fixed now. Fix for bug 135048 landed on the trunk and branch.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verif fixd.
Status: RESOLVED → VERIFIED
04/10/2002 02:48varga%utcru.sk mozilla/ layout/ xul/ base/ src/ tree/ src/ nsTreeBodyFrame.cpp 1.118.2.2 MOZILLA_1_0_0_BRANCH 1/1 adding fixed1.0.0 keyword to resolve this for the 1.0 branch.
Keywords: fixed1.0.0
This bug is still here. I am running build 2002051507 on RH7.2 and it is currently behaving as described in this bug. In fact, it seems to be worse than I recall. Clicking the 'scroll down' button can actually cause the messages to scroll the wrong way - still causing the last message(s) to not be visible. I would like to change this from it's 'FIXED' state, but the page doesn't seem to give me the option. Max.
Works fine in OS/2 2002051508 trunk.
> Works fine in OS/2 2002051508 trunk. Since it is an intermittent problem, I think only time can tell if it doesn't occur on any particular platform. I don't have access to OS/2 - only Linux, IRIX, and OS X - I will keep an eye on each of the platforms to see if it occurs on those too. I guess it might be something to do with the way I use it or have it configured. We will see, I guess. Max.
*** Bug 140155 has been marked as a duplicate of this bug. ***
This bug is still here in 2002052723. It seems to appear more often after I have used the 'Subject or Sender contains:' function and have hit the 'Clear' button to return to normal. After that, the side bar will not scroll down to the bottom of the messages - it isn't just the bottom message because there is more than one off the bottom of the pane. Resorting the messages didn't help, but putting another string in the 'Subject or...:' field and hitting 'Clear' again returns it to normal. Please move this from 'FIXED' because it isn't. Thanks. Max.
Max, you seem to be describing a different bug. (In particular, this bug was _not_ about not being able to scroll to the bottom of the outliner -- you could do that fine. This bug was about mouse events not going to the right place.)
Ah, fair enough. I guess I misunderstood the original request - sounded a lot like the same thing. Should I open another bug, or is there one already open that I cannot find? Max.
Max Waterman: not being a ble to scroll to the last attachment was reported in bug 140190 (i don't see it anymore on linux though)
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.