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)
Tracking
()
VERIFIED
FIXED
M14
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.
Comment 3•25 years ago
|
||
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+]
Comment 5•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
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
Assignee | ||
Comment 8•24 years ago
|
||
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
Assignee | ||
Comment 9•24 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: M14
Comment 10•24 years ago
|
||
verif w/opt comm bits [2000022108] on winNT and linux.
Status: RESOLVED → VERIFIED
Comment 11•24 years ago
|
||
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.
Description
•