Closed Bug 20452 Opened 20 years ago Closed 20 years ago
[HELP WANTED][DOGFOOD][Tree] should hide scrollbar when its frames go away
When a tree widget is hidden by a tab panel (by setting the enclosing <box> to display:none) it should hide its scrollbar, otherwise it will bleed through to the top of the tabpanel...
Summary: Tree widget should hide it's scrollbar when it's frames go away. → Tree widget should hide its scrollbar when its frames go away.
Weird. I don't know why that wouldn't be working automatically.
yeah, I went home and thought about it, I can't figure it out either. I'm going to poke s'more at this now. Marking dogfood because this affects AIM usability.
Status: NEW → ASSIGNED
Summary: Tree widget should hide its scrollbar when its frames go away. → [DOGFOOD][Tree] should hide scrollbar when its frames go away.
Putting on PDT+ radar. Unfortunate that scrollbar is there. But will not affect dogfood. Please remove PDT- if you have more info on how critical this is to AIM. Be happy to reconsider.
cool, marking M13.
reassigning tree bugs back to hyatt. this bug may even already be fixed. It would be great if the QA contact here could verify this bug is still broken.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
This should be fixed now that trees are views.
I'd be happy to reconfirm/verify this bug if someone wants to provide a testcase and/or some steps to reproduce.
the testcase is AIM - it has two trees in a tabbed panel. The problem I was seeing was that some times, when you switched from the buddy list to the list of logged on buddies, the scrollbar from the OTHER panel would be the visible one. The only way you'd know this is: switch from one panel to the other. If the thumb size/position do not change, then you may have the other scrollbar. To check this, try scrolling by dragging the thumb or clicking the up/down buttons. If the visible tree does not scroll, you may have moved the other tree's scrollbar. Switch back to the original panel, and see if that tree has scrolled at all. This didn't happen all the time though, so try this a few times.
Whiteboard: [PDT-] → [PDT-] 13-JAN can't sign on AIM - blocking verification
I still see this problem in Aim. The scroll bar does not seem to recognize tab switches and widnow content changes. A simple testcase using Aim is: 1. Launch seamonkey 2. Login to Aim (observe all groups are empty and collapsed, so no scroll bar) 3. Tab to ListSetup Panel 4. Add three buddies to each group. (Toolbar has addbuddy icon) 5. Open all groups, so that scroll bar shows up 6. Tab back to Online Panel Expected result: Online panel does not have scrollbar Actual result: Because listsetup has scrollbar, online panel remembers that and still has scrollbar
Summary: [DOGFOOD][Tree] should hide scrollbar when its frames go away. → [HELP WANTED][DOGFOOD][Tree] should hide scrollbar when its frames go away.
Can someone construct a simple reduced XUL test case for this bug? Marking HELP WANTED.
I'm still seeing this problem in AIM - reopening. Hyatt- if you're having trouble repro-ing this, please feel free to come by my cube to check it out.
Resolution: FIXED → ---
Whiteboard: [PDT-] 13-JAN can't sign on AIM - blocking verification → [PDT-]
clearing the FIXED resolution due to reopen
I have tried to come up with a aim test case. To run this, the following security prefs under defaults/prefs/all.js must be made false pref("security.checkuri", false); pref("security.checkdomprops", false); pref("security.checkxpconnect", false); These are true by default. Changing QA contact since verification is easier in Aim
A test case without AIM. Something small and simple... just XUL to demonstrate the problem. I'm trying to avoid pulling and building the commercial tree, since I don't have enough disk space at home to do so.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Never mind! The Themes panel in prefs was doing it. I NAILED IT. On fire tonight, baby.
YEAH! GO, BABY! Fixed in AIM too!
fixed in Aim :-) Verified with 20000119 builds.
You need to log in before you can comment on or make changes to this bug.