Closed Bug 204770 Opened 20 years ago Closed 20 years ago

Folders in Personal Toolbar Folder and advanced toolbar button options don't collapse automatically

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4final

People

(Reporter: vedran, Assigned: danm.moz)

References

Details

(Keywords: regression)

Attachments

(1 file)

revert bug 192577's change to nsMenuPopupFrame.cpp
2.50 KB, patch
bryner
: review+
roc
: superreview+
asa
: approval1.4+
Details | Diff | Splinter Review 
Regression - In 2003050708, when folder in bookmarks toolbar folder is clicked
on while another is already open, it opens but other one doesn't close.
Steps to reproduce:
1. Have at least two folders (with some bookmarks) in Personal toolbar folder.
2. Expand first one. Don't collapse it.
3. Now expand second one.
It will not expand on first click, but on the second, and when it expands first
one will not be collapsed.
no blocker
Severity: blocker → major
Flags: blocking1.4?
Keywords: regression
Flags: blocking1.4b?
I guess it's a regression from bug 192577 that touched nsMenuPopupFrame.cpp.
cc'ing aaronl, reviewers and commiter.
If this bug is a regression from bug 192577, this one should be fixed by backing
out the other, marked as having minor severity. I´m having 1 MB bookmarks in 18
visible folders in the personal toolbar, and some more folders in the overflow,
this bug forces me to stick with latest working nightlie, i.e. 2003050509.

Yes this is a regression from bug 192577. Interestingly, backing out just the
changes to nsMenuPopupFrame.cpp seems to fix this bug without reverting the fix
for that bug. I'm investigating (and taking: I was in on that 192577 thing, it
seems only fair.)
Assignee: chanial → danm
No kidding, simply backing out bug 192577's change to nsMenuPopupFrame.cpp
fixes this bug and doesn't hurt the fix for that bug. This puts
nsMenuPopupFrame::ConsumeOutsideClicks back as it was, and leaves the 192577
fix with only the changes to windows widget code and to autocomplete.xml. Seems
enough. Corroboration would be nice. I've tried this on WinXP, OSX and RedHat8.
Attachment #122711 - Flags: superreview?(roc+moz)
Attachment #122711 - Flags: review?(bryner)
Note this is a fairly nasty glitch: currently you can have multiple personal
toolbar menu windows open simultaneously, layered atop one another. I've also
managed to leave a personal toolbar menu window marooned on my desktop after I
moved the browser window away.
Flags: blocking1.4b?
Flags: blocking1.4?
Flags: blocking1.4+
Could the cause for this bug be also the cause for crash when dragging bookmars
in and out of folders in Personal Toolbar Folder?
bug 204781. Nope, that's different (and much worse!).
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4final
Comment on attachment 122711 [details] [diff] [review]
revert bug 192577's change to nsMenuPopupFrame.cpp

I'd suggest keeping the additions to the table of click-eating as they are. 
Other than that, r=bryner.
Attachment #122711 - Flags: review?(bryner) → review+
*** Bug 204996 has been marked as a duplicate of this bug. ***
The weird thing is that same thing happens with toolbar buttons too, check this:
have at least one back entry, and try clicking that dropdown arrow at "Back" -
now click at the same arrow at "Print preview" - exactly the same thing.
Component: Bookmarks → XP Apps: GUI Features
Summary: Folders in Personal toolbar folder don't close automatically → Folders in Personal Toolbar Folder and advanced toolbar button options don't collapse automatically
Attachment #122711 - Flags: superreview?(roc+moz) → superreview+
*** Bug 205151 has been marked as a duplicate of this bug. ***
Comment on attachment 122711 [details] [diff] [review]
revert bug 192577's change to nsMenuPopupFrame.cpp

a=asa (on behalf of drivers) for checkin to 1.4
Attachment #122711 - Flags: approval1.4+
*** Bug 205234 has been marked as a duplicate of this bug. ***
*** Bug 205288 has been marked as a duplicate of this bug. ***
*** Bug 205355 has been marked as a duplicate of this bug. ***
*** Bug 205354 has been marked as a duplicate of this bug. ***
.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Oops. Forgot to mention I didn't leave the click-eating comment table as-is
(comment 10). That table describes context menu changes that were backed out, so
it seems more appropriate to also back out the description. Anyway, bug's fixed.
I've installed nightly build 2003051216 but the problem still there...
How do i know from what build is it supposed to be fixed up ?

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030513
seems to be partly working, but I did an upgrade install only.
Will retry later with clean install.

If I open a folder in my personal toolbar, it expands, and when I click another,
it collapses, and I must click second time, that the other folder expands.

If I open a folder which contains a subfolder, and hover over this subfolder,
I see the old behaviour, even worse. I tried this while typing here, and I had
to close all folders before I could place a cursor here to continue typing.
Ignore comment 21, i've downloaded just now the 2003051305 and there are some
improvements, but menù handling is far to be perfect !
Please refer to bug 142215, in my humble opinion requiring two click to open
another folder when the previous one is opened seems wrong behaviour to me, i
can also confirm the bug at comment 22.
I suggest to reopen this bug because comment 22, also have a look at bug 142215
for the implementation of a better menu navigation on personal toolbar

*** Bug 205477 has been marked as a duplicate of this bug. ***
Bug not fixed, please reopen.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030513
after deinstallation of previous installation installed in empty directory,
Win98 SP1 and Win98SE, both showing behaviour as described in comment #22.

i.e. bug seems to be fixed, if you use only files and folders in the P.T.
bug not fixed, if folders in folders in the P.T. are opened.

But I´m glad about the progress in this bugfix.
"If I open a folder in my personal toolbar, it expands, and when I click another,
it collapses, and I must click second time, that the other folder expands."

That is the same behavior as in Mozilla 1.3. This bug was a regression. It is
now fixed. Other issues should be addressed in other bugs.

Thanks to Dan and everybody for fixing the bug.
Comment #22 happens here also (Windows Server 2003).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Re: comment #26

That part is fixed, yes.
But was this bug a regression, or part of a regression?
If different files or subroutines were broken, I would say it was a regression,
and that other part was another. If the broken code was in the same subroutine,
imho this bug would be only part of a regression and should be reopened.
But I would leave this decision to the people knowing the code.

Should it make a difference, if I open a folder, or a folder in a folder, and
then change to another folder? That part is not fixed.
And I thought it to be logical to comment this here, because this is the same
part of code, the same action, and the same team of contributor and reviewers,
who might have an idea, and could file this bug better than me.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
If I open a folder in my personal toolbar, hover over a folder in it, and over a
folder in that, two subfolders are open, and if I then hover up to another
folder on the PT, the subfolders are closed, the original folder in the PT is
still open, the new folder in the P.T. marked selected. One click only, and the
old folder collapses and the new one opens.

Should the bug be reopened, or a new one filed?

I wrote first part of this comment while using Mozilla 1.3 testing what I
described. Now I´ve repeated the same with BuildID 2003051305
If I´m slow with the mouse, subfolders are collapsing. If I´m fast with the
mouse, and get to the Personal toolbar before subfolders are collapsed, they
stay. My workaround: Move a fileentry as first item into the folder, and then
the subfolders, and don´t be too fast with the mouse.

So I found my workaround, want to say Thanks to all contributing to this fix, 
If got no more to comment on this bug, and accept any decision of a developer,
even none ;-)
Don't know if it helps, but for me the last working build without this bug is
2003050610 (note: bug 192577 is present). 

I've also noticed that after opening the first folder, when I try to open the
second one it would open and quickly close straight away. Clicking on it the
second time would usually succeed and you end up with both being open.
*** Bug 205713 has been marked as a duplicate of this bug. ***
Dan, Aaron, we still have some of the problem here. 

Steps to reproduce: 
1. create two folders in the personal toolbar folder "foo" and "fred"
2. within "foo" create sub-folder "bar"
3. within "bar" create a sub-folder "baz"

Now you've got an empty "fred" folder on your personal toolbar and a "foo"
folder which has a sub-folder named "bar" which has a sub-folder named "baz".

4. click on "foo" to open the folder.
5. move the mouse down over the "bar" folder and it will pop open the reveal "baz".
5. move the mouse into "baz".
6. move the mouse out of baz and back up to the personal toolbar.
7. click on the folder "fred".

Results: the "fred" folder opens and closes and the foo/bar/baz/ folders stay open.

Additional results:
If rather than following step 7. you click "foo" the foo/bar/baz folders close
but clicking a second time on "foo" opens and closes them foo rather than
opening it and leaving it open.
*** Bug 205847 has been marked as a duplicate of this bug. ***
re: comment 26 and comment 28.

Please note that this is not fully fixed even with the simplest folders in the
toolbar (even if much imporved). If you explicitely, via right mouse button and
 context menu choose to Expand the folder, it will stay open.

I can't find any comments anywhere about a problem I see with the context menu
of a normal bookmark in the P.T. Such a context menu don't collaps if I continue
by expanding a bookmark folder in the P.T. Even if this migth be related to
current bug it probably should be filed as a new one.
Well I finally understand the original (bug 192577) problem, and why reverting
nsMenuPopupFrame appeared to fix it but doesn't really. The issue is that menus
must be closed at the beginning of a mousedown, before some new menu could
potentially be opened by that same mousedown. (Or rework some things in layout
that I'm not anxious to take on.) The fundamental problem is that sometimes (for
bug 192577) the menu wants to be left open until we've determined what the new
menu will be. It's a scratcher. It's time to consider which of the two bugs is
more onerous.  I'm still looking but kind of stumped.

comment 33: there's a context menu on bookmark folder items?
Well this is just a suggestion, but the bahavior in most menus (at least in the
Windows environment) is that mousing over a different folder opens that folder
and closes the first without any clicking. If you go to your menu bar, click on
file, you can just move through edit, view, ect and the menus open following the
mouse focus. Why not use the same method/code on folders in the personal
toolbar? Obviously it would have to be revised to handle folders within folders,
but since it works ok in the bookmarks menu on the menubar I don't see why it
couldn't be made to work on personal toolbar the same way. 
Dan, how hard would it be to create a widget just for the URL bar's drop marker?
Then it could be part of that widget chain thing.
*** Bug 203899 has been marked as a duplicate of this bug. ***
*** Bug 205937 has been marked as a duplicate of this bug. ***
*** Bug 206189 has been marked as a duplicate of this bug. ***
Blocks: 206059
Re comment #34: Yes there is such a context menu on folders in the personal
toolbar. At least on win.

These toolbar menus seems to bring out quite a few bugs; you can also get the
expanded menus of the main Menu Bar to stick if you; 
 1. expand one of the menus on the main Menu Bar
 2. expand one toolbar menu (e.g. a bookmark folder on personal toolbar),
which is a slight variation of this bug and the depending bug 206059.
Dan, Aaron, let's just back out the rest of bug 192577. That bug was far less
painful than the regressions. 
I was unable to find a proper fix for this bug that would also keep bug 192577
fixed. It's all been backed out. I'm closing this one and reopening the other.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
*** Bug 206637 has been marked as a duplicate of this bug. ***
No longer blocks: 206059
*** Bug 206059 has been marked as a duplicate of this bug. ***
Perhaps this is overly simple, but ... shouldn't the folder on bookmark toolbar
collapse the moment I mouse-off?!
And more.  I think the "cua standard" is to open the next one you mouse onto.
I don't understand why this has been set resolved/fixed.  I'll leave that to
others to determine.  Thanks for investigating this one.

-m-

> If you explicitely, via right mouse button and context
> menu choose to Expand the folder, it will stay open.

Already filed as a separate bug. Hasn't that code path has been removed anyway?
v
Status: RESOLVED → VERIFIED
*** Bug 207030 has been marked as a duplicate of this bug. ***
*** Bug 207173 has been marked as a duplicate of this bug. ***
Does the resolution make its way into nightly after the status becomes VERIFED 
or CLOSED?  I have looked at the 03-05-28 nightly but it does not contain the 
fix.  Any URL to documentation of the process will be appreciated.

Comment 51:
It works for me correctly since 20030522 builds, what's happening on your side?
Comment 52:
The bug I posted (Bug 203899) was marked a duplicate of this bug (Comment 
#37).  That bug still exists.  I see now that this bug has a slightly different 
wording to my bug.  The DUPLICATE resolution of Bug 203899 was probably in 
error.  Could Bug 203899 be reopened?

I have installed Mozilla 1.4 Release Candidate 1 and the original problem I
reported (in this bug) has been resolved in this release according to my own
testing.

The behaviour of a drop-down Bookmark menu is still different than the standard
CUA menu such that you must click it again to close it.  Actually i could get
used to this :)

Nice work.  Looks sweet.

-m-
I have installed Mozilla 1.4 Release Candidate 1 and the original problem I
reported (in this bug) has been resolved in this release according to my own
testing.

The behaviour of a drop-down Bookmark menu is still different than the standard
CUA menu such that you must click it again to close it.  Actually i could get
used to this :)

Nice work.  Looks sweet.

-m-
*** Bug 209420 has been marked as a duplicate of this bug. ***
for me the bug is new and now
it is a bug!

This means that the described error happens every second time again.
V 1.4b

karlo
I don't understand what did you just say.
Please, give us more details.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.