Hierarchy menus detach at second level folders.

VERIFIED FIXED in mozilla0.9.1

Status

SeaMonkey
MailNews: Message Display
P2
normal
VERIFIED FIXED
17 years ago
6 years ago

People

(Reporter: laurel, Assigned: Paul Chen)

Tracking

Trunk
mozilla0.9.1
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Checked in on Trunk, need verification before Branch)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Using apr30-may01 commercial builds linux rh6.2 and Win98
Mac appears fine.

This has been around awhile but seems to be getting worse -- at least it's more
in my face than before. Very hard to use sometimes...

When you try to access the second sub-level (or deeper) of a folder hierarchy
menu such as File/Move/Copy, the submenu detaches at the second level folders
level.  When that next level detaches from the rest of the menu, it REALLY
detaches and often displays at the opposite end of the screen making it quite
difficult to secure a selection.

This affects the File/Move/Copy menus, search UI scope dropdown and File button
menu, and probably New Folder dialog, too.

This really needs to be fixed.
(Reporter)

Updated

17 years ago
Keywords: nsbeta1
QA Contact: esther → laurel
Summary: Hierarchy menus detach at second level folders. → Hierarchy menus detach at second level folders.

Comment 1

17 years ago
I think this is an xptoolkit bug.  Reassigning to pinkerton.  I see this a bunch
too.
Assignee: sspitzer → pinkerton
ben? are you ever going to check in your menu fixes?
Assignee: pinkerton → ben
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 3

17 years ago
nav triage team:

1. So did Ben just go and fix these issues many moons ago?
2. Why haven't these fixes been checked in?
(Assignee)

Comment 4

17 years ago
Ok, talked to Ben and Pink about this. The patch has possibly bitrotted on Ben's
Mac, and Ben said that he sent the patch to Pink. Pink has just showed me this
patch which is in bug 66848. We're not sure that the patch will fix this bug
until we apply it and test it out. If I ever feel safe about pulling a tree
something this week, I might get around to testing the patch out.
(Assignee)

Comment 5

17 years ago
nav triage team;

Reassigning to pchen to test patch for 66848
Assignee: ben → pchen
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Updated

17 years ago
Priority: -- → P2
(Assignee)

Comment 6

17 years ago
I applied the patch to bug 66848 at home under linux, and it doesn't seem to
make a difference. However, I don't have access to an imap server with nested
folders. Creating a nested local folder hierarchy doesn't seem to cause any
problems. Will try again tomorrow at work.
(Assignee)

Comment 7

17 years ago
Maybe it's just me, but I can't see this problem. I guess my imap mailbox just
isn't complicated enough. Can anyone else reproduce with a recent build? (I just
tried 2001051604, but I don't think it's the build, more likely my setup)

Comment 8

17 years ago
I'm using 5/15 and I'm not seeing it right now.  It didn't happen to me all of
the time unfortunately, but right now I can't reproduce it.
(Reporter)

Comment 9

17 years ago
On win98 and linux with may15 commercial build, I can easily see it when
selecting the scope for Search Mail/News Messages or in the MoveToFolder action
section of the Filter Rules dialog or if using the dropdown in New Folder from
main mail window... I don't, however, see it when using the File button or
Move/Copy dropdowns.
(Reporter)

Comment 10

17 years ago
Mac, too, may15 trunk build.
(Reporter)

Comment 11

17 years ago
Esther's experiencing it, too, on her windows system today's build in main mail
File button dropdown.  I'm seeing weirder problems in today's build with the
file menu, will log separately.
(Reporter)

Comment 12

17 years ago
New problems in today's build logged as  bug 81252
(Reporter)

Comment 13

17 years ago
OK, fairly easy to reproduce on main mail window (win98):
1. Have a hierarchy with at least one account having lots (20?) of top level
folders and some of those which have several sublevel folders.
2. Login, select a message in a folder.
3. Put window in restored state, move window down so it is significantly off the
bottom of the screen, say just a couple inched of the top of the window showing
-- only a couple lines of the thread pane visible.
4. Click File button and select the account having lots of folders.  The
sublevel of the dropmenu will detach to the far left of the screen. Further
sublevel menus will appear detached in somewhat random parts of the screen.
(Assignee)

Comment 14

17 years ago
Ok, I've got this to reproduce on my linux build without the patch for 66848. On
my win2k box with the patch, it looks fixed. So I think we've got a winner here.
Pinkerton says that he also wants to make sure mac is fixed too. I'll apply the
patch to my powerbook tomorrow. So far, I'd say it looks like we have a winner.

Updated

17 years ago
Whiteboard: fix in hand, but need to get it checked in asap

Updated

17 years ago
Whiteboard: fix in hand, but need to get it checked in asap → fix in hand, need testing, needs to be checked in by 5/23.
Not sure if we can keep this indefinitely as a beta stopper. We shd make sure we 
have a winner with the current patch, and if so, get it in asap. 

Comment 16

17 years ago
Shouldn't the patch be attached to the bug?

If we have the right patch, we should get this checked in when ready.
(Assignee)

Comment 17

17 years ago
Created attachment 35841 [details] [diff] [review]
patch from bug 66848
(Assignee)

Comment 18

17 years ago
Just copied patch from bug 66848. Although fixing windows and linux, this patch 
trades one bug for another on mac. On the mac, submenus don't show up the first 
time you select them, and on subsequent tries, the submenu is empty. So I don't 
think the patch is ready. I'm thinking it will take on the order of a 2-3 days 
for me to fix the mac problem caused by the patch, mainly because I'm not that 
familiar with the code.
(Assignee)

Comment 19

17 years ago
Updating status whiteboard. In debugging, I got as far as finding out that
submenus of the bookmarks popup menu on the personal toolbar are coming up blank
because the titles of all the menu items are blank (well, the empty string).
Pinkerton, Ben, and myself are all puzzled as to why this patch cause that
effect, especially only on the mac. Further investigation will require me to
traipse through the creation of the popup menu in the xul template builder. It's
looking like another couple days of working on this only to fix.
Whiteboard: fix in hand, need testing, needs to be checked in by 5/23. → patch hoses mac, still investigating, needs to be checked in by 5/23.
(Assignee)

Comment 20

17 years ago
The further I dig, the stranger it gets. So as far as I can tell, layout is
building the submenu a couple times, but when it goes to draw the submenu, it
draws using a completely DIFFERENT set nsTextBoxFrame objects that we so
painstakingly create. It just so happens that those nsTextBoxFrame objects have
empty string titles. Sigh. Adding pinkerton and ben to cc list.
(Assignee)

Comment 21

17 years ago
Ok, I'm going to go off into a corner and weep profusely. The problem I'm seeing
is bug 80512. Open a second window, and the bookmarks menu works fine on mac.
Updating status whiteboard. Waiting for r= and sr=.
Whiteboard: patch hoses mac, still investigating, needs to be checked in by 5/23. → I'm an idiot, awaiting r= and sr=, needs to be checked in by 5/23.
(Assignee)

Comment 22

17 years ago
Got an r=pinkerton. Adding alecf to cc for possible sr
Whiteboard: I'm an idiot, awaiting r= and sr=, needs to be checked in by 5/23. → I'm an idiot, awaiting sr=, needs to be checked in by 5/23.

Comment 23

17 years ago
wow. I really need to defer this to hyatt - but I have to add that the tabs are
screwed up :)
pchen is now in Taiwan - I really don't have a mac handy, is there someone who
can take this?

Updated

17 years ago
Whiteboard: I'm an idiot, awaiting sr=, needs to be checked in by 5/23. → wanted for 0.9.1 awaiting sr= and a=

Comment 24

17 years ago
sr=hyatt

Comment 25

17 years ago
a= asa@mozilla.org for checkin to 0.9.1 and the trunk.

Comment 26

17 years ago
ok, I'll check this into the branch and trunk, since paul is away
Whiteboard: wanted for 0.9.1 awaiting sr= and a= → have r=,sr=,a=, alecf to checkin to branch and trunk
i must admit i'm a bit wary of landing this on the branch. it's a major change
and it's been around for so long, with so many false-starts, that i'm just plain
scared especially so close to beta.

Comment 28

17 years ago
alecf, pchen,  can you just check this into the trunk.  If everything looks good
in a day or two and we haven't released yet we can look at it for the branch. 
Sorry for the premature approval and any confusion.
(Assignee)

Comment 29

17 years ago
This has just been checked onto the trunk

Updated

17 years ago
Whiteboard: have r=,sr=,a=, alecf to checkin to branch and trunk → Checked in on Trunk, need verification before Branch

Comment 30

17 years ago
I have filed a bug introduced by this patch as bug 84121. It was commented on 
bug 78409 (2001-03-31 06:46).
(Reporter)

Comment 31

17 years ago
I just tried the jun05 commercial trunk build on win98, mac OS 9.0, and linux
rh6.2 and cannot get the separation problem anymore. Looks okay to me.

Comment 32

17 years ago
how could we build a set of test cases that would convince us 
that we didn't regress something else with this checkin...

do we just need to pound the heck out of menus to confirm the fix?

is there anything else we could do to shake out side effects?  

Comment 33

17 years ago
If 84121 results in menus with unselectable items then I think we need that fix
to come along with this one.  Any other opinions?
Depends on: 84121

Updated

17 years ago
No longer depends on: 84121
(Assignee)

Comment 34

17 years ago
So, I haven't seen an a= for the branch, if I don't see anything soon, I assume
this is a no go for the branch.

Comment 35

17 years ago
a=chofmann on the branch
(Assignee)

Comment 36

17 years ago
checked into the branch, marking fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 37

17 years ago
OK with commercial branch 2001-06-06-12-0.9.1 win98
(Reporter)

Comment 38

17 years ago
Looks ok to me, no detached menus on the commercial branch builds:
OK with 2001-06-06-12-0.9.1 on mac OS 9.0 
OK with 2001-06-06-13-0.9.1 on linux rh6.2

Note:  On mac I do see lag  time in drawing the submenus and will sometimes
flash a blank white submenu before correctly drawing the correct contents... but
I've seen this same effect previously when I'm in the condition spelled out in
bug 80512.  I don't see any separation, no detaching.  So I'm marking this one
verified.
Status: RESOLVED → VERIFIED
FYI, the flashing submenus should only happen the first time the submenu is
created. It's RDF streaming in bookmarks asynchronously, so the window gets an
initial size then resizes to the correct size when the content is built, causing
the flashing.

Comment 40

17 years ago
It seems that this bug fix solved a related bookmark bug 62525 at the rame time
intrducing a bookmark regression 85180. This regression (no arrow at the bottom
of the screen if the sub menu is not fully visible) should probably be seen with
long list of mail sub-folders, too.

Comment 41

17 years ago
The regression bug mentioned above is bug 84121. The newer 85180 is only its dup.
Product: Browser → Seamonkey

Comment 42

13 years ago
*** Bug 157780 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.