Closed Bug 27963 Opened 25 years ago Closed 24 years ago

Tasks | Mail menu disappears from Browser menu when cursor placed in Nav location field

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: momoi, Assigned: hyatt)

Details

(Keywords: platform-parity, Whiteboard: [PDT+])

** Observed with 2/15/2000 Win32 build **

I have seen this problem before but finally was able to isolate 
the actions which cause this problem with the above build.

1. Start up Browser.
2. Check the Task menu and confirm that "Mail" menu is there.
3. Now click the cursor into the Navigator location field (URL field).
4. Now re-check Task menu. This time "Mail" menu is replaced by
   something else.
5. Close Task menu. Now clcik on some other menu like "HELP"
   and come back to Task menu. Now it shows something other than
   what you see in step 4 above. You can repeat process
   by oopening ohter menus and everytime some other item would
   show in place of "Mail".

This makes the "Mail" menu inaacessible. If you try to select it,
it normally crashes Mozilla. I think this is pretty serious.
Nominate for beta1
Keywords: beta1
This has view manager written all over it.
Assignee: pinkerton → beard
ooh, yeah. saw this on linux (2000-02-16-09 comm bits) as well as winNT
(2000-02-16-08 non-comm).
Keywords: pp
Putting on PDT+ radar for beta1.
Summary: Taks | Mail menu disappears from Browser menu when cursor placed in Nav location field → Tasks | Mail menu disappears from Browser menu when cursor placed in Nav location field
Whiteboard: [PDT+]
With 2000-02-17-M14 on Windows NT, something similar is happening to any of the 
menus that appear entirely over the text inside the URL bar, once a URL is
loaded. This can include the Tasks, Help, Debug, and QA menus, depending
on the length of the URL. There is a white band in the menu corresponding
to the area taken up by a selection box on the URL text, including the part
of the Tasks menu where the Mail item would normally appear.
No crash or hang seen, though.
Giving new bugs to kevin.
Assignee: beard → kmcclusk
OK, here is what's happening. The zindex for the popup menuview is set in 
nsMenuPopupFrame.cpp with a call to

viewManager->InsertChild(rootView, ourView, kMaxZ); at line 141.

Later a reflow happens to the nsMenuPopFrame.cpp which resets the zIndex for the 
view based on CSS style context. Since the Zindex has not been specified through 
style it resets the menu popup's view to 0. This is the bug, we can not set the 
zIndex programatically and expect it to stick. The CSS z-index property must be 
set for the menu popup's so that during reflow the zindex for the view will be 
set to the appropriate value. As a test I modified global.css at line 739 to 
include a z-index property

/* XXX menupopups have to have a c
menupopup, popup {
  background-color: #CCCCCC;
  border: 1px solid #336699;
  z-index:255;
}

This fixes the bug. We should set a very large value for z-index (CSS equivalent 
of maxint) for the z-index.

Reassigning to hyatt for the global.css change
Assignee: kmcclusk → hyatt
I just copied this code from the combo box a long time ago.  :)

What do I change the InsertChild call to if I don't pass in max z-index?  Is the 
combo box specifying its z-index through style as well?  
Status: NEW → ASSIGNED
fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: M14
verif w/opt comm bits [2000022108] on winNT and linux.
Status: RESOLVED → VERIFIED
The combobox sets the zindex both through style and through the call: 
viewManager->InsertChild(rootView, ourView, kMaxZ); 
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.