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

VERIFIED FIXED in mozilla1.4final

Status

SeaMonkey
UI Design
--
major
VERIFIED FIXED
15 years ago
10 years ago

People

(Reporter: Vedran Miletic, Assigned: Dan M)

Tracking

({regression})

Trunk
mozilla1.4final
x86
Windows 2000
regression
Bug Flags:
blocking1.4 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
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
(Reporter)

Updated

15 years ago
Flags: blocking1.4b?

Comment 3

15 years ago
I guess it's a regression from bug 192577 that touched nsMenuPopupFrame.cpp.
cc'ing aaronl, reviewers and commiter.

Comment 4

15 years ago
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.
(Assignee)

Comment 5

15 years ago
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
(Assignee)

Comment 6

15 years ago
Created attachment 122711 [details] [diff] [review]
revert bug 192577's change to nsMenuPopupFrame.cpp

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.
(Assignee)

Updated

15 years ago
Attachment #122711 - Flags: superreview?(roc+moz)
Attachment #122711 - Flags: review?(bryner)
(Assignee)

Comment 7

15 years ago
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.

Updated

15 years ago
Flags: blocking1.4b?
Flags: blocking1.4?
Flags: blocking1.4+
(Reporter)

Comment 8

15 years ago
Could the cause for this bug be also the cause for crash when dragging bookmars
in and out of folders in Personal Toolbar Folder?
(Assignee)

Comment 9

15 years ago
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+

Comment 11

15 years ago
*** Bug 204996 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 12

15 years ago
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+

Comment 13

15 years ago
*** Bug 205151 has been marked as a duplicate of this bug. ***

Comment 14

15 years ago
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+

Comment 15

15 years ago
*** Bug 205234 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
*** Bug 205288 has been marked as a duplicate of this bug. ***

Comment 17

15 years ago
*** Bug 205355 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
*** Bug 205354 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 19

15 years ago
.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 20

15 years ago
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.

Comment 21

15 years ago
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 ?

Comment 22

15 years ago
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.

Comment 23

15 years ago
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

Comment 24

15 years ago
*** Bug 205477 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
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.

Comment 26

15 years ago
"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.
(Reporter)

Comment 27

15 years ago
Comment #22 happens here also (Windows Server 2003).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 28

15 years ago
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 ;-)

Comment 29

15 years ago
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.

Comment 30

15 years ago
*** Bug 205713 has been marked as a duplicate of this bug. ***

Comment 31

15 years ago
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.

Comment 32

15 years ago
*** Bug 205847 has been marked as a duplicate of this bug. ***

Comment 33

15 years ago
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.
(Assignee)

Comment 34

15 years ago
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?

Comment 35

15 years ago
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. 

Comment 36

15 years ago
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.

Comment 37

15 years ago
*** Bug 203899 has been marked as a duplicate of this bug. ***

Comment 38

15 years ago
*** Bug 205937 has been marked as a duplicate of this bug. ***
*** Bug 206189 has been marked as a duplicate of this bug. ***

Comment 40

15 years ago
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.

Comment 41

15 years ago
Dan, Aaron, let's just back out the rest of bug 192577. That bug was far less
painful than the regressions. 
(Assignee)

Comment 42

15 years ago
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
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
*** Bug 206637 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
No longer blocks: 206059
(Assignee)

Comment 44

15 years ago
*** Bug 206059 has been marked as a duplicate of this bug. ***

Comment 45

15 years ago
Perhaps this is overly simple, but ... shouldn't the folder on bookmark toolbar
collapse the moment I mouse-off?!

Comment 46

15 years ago
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-

Comment 47

15 years ago
> 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?
(Reporter)

Comment 48

15 years ago
v
Status: RESOLVED → VERIFIED

Comment 49

15 years ago
*** Bug 207030 has been marked as a duplicate of this bug. ***

Comment 50

15 years ago
*** Bug 207173 has been marked as a duplicate of this bug. ***

Comment 51

15 years ago
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.
(Reporter)

Comment 52

15 years ago
Comment 51:
It works for me correctly since 20030522 builds, what's happening on your side?

Comment 53

15 years ago
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?

Comment 54

15 years ago
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-

Comment 55

15 years ago
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. ***

Comment 57

15 years ago
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
(Reporter)

Comment 58

15 years ago
I don't understand what did you just say.
Please, give us more details.
Product: Core → Mozilla Application Suite

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.