Closed Bug 67574 Opened 24 years ago Closed 24 years ago

Can't open (some) menus after switching themes

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mbialkowski, Assigned: bugs)

References

Details

(Keywords: regression)

Attachments

(1 file)

Fix.
1.02 KB, patch
Details | Diff | Splinter Review
Using 2001020309 build, switching to a new skin will prevent the View, Search, and QA dropdown menus from actually dropping down until you restart Mozilla. You can click on them; the menu just won't appear.
Confirming for 2001/02/02/20 build on Win2k. Platform and OS should be ALL.
-> hyatt
Assignee: hewitt → hyatt
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Themes → XP Toolkit/Widgets: Menus
Ever confirmed: true
Keywords: mozilla0.8, nsbeta1, regression
OS: Linux → All
QA Contact: pmac → jrgm
Hardware: PC → All
Summary: Switching skins disables certain menubar items → Can't open (some) menus after switching themes
*** Bug 67660 has been marked as a duplicate of this bug. ***
*** Bug 67660 has been marked as a duplicate of this bug. ***
I can confirm this on WinNT 4.0 (sp5) running Build 2001020520. One thing though: it only seems to affect the first browser window opened. If you open another window all the menus drop down properly. BTW: It affects these menus: View Search Go Bookmarks Tasks
this is ugly and highly visible. would be great to see this fixed for 0.8
Whiteboard: critical for mozilla 0.8
I know how to fix this.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
sr=brendan@mozilla.org (brendan using hyatt's iMac). /be
Attached patch Fix. — — Splinter Review
a=asa-driver Does this still need review or is it ready to go?
hyatt, get ben to r= so he can buddy xbl better. /be
Any chance this fixes bug 51996?
*** Bug 68077 has been marked as a duplicate of this bug. ***
fixed.
Fixed the XBL issues. I notice that some menus in Navigator still don't open, but it's unrelated to my checkins or to insertion points.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Random menus still don't open after switching themes, just as they didn't before this fix. I'm not convinced this is fixed, so reopening even if to reassign and handle the other problem hyatt referred to...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
And also, this isn't Navigator-only. I'm assuming you used the View menu to switch, but if you switch from the theme pane in a prefs dialog launched from Mail or Composer, you'll see similar problems (although confined to the Edit menu, it seems).
Sorry.... Nevermind about it being confined to Edit. I just saw it for almost every menu in Editor.
I'm still seeing this, too. I just opened Mozilla fresh, switched themes to Blue in navigator, and then Edit and View menus didn't open. I opened a new navigator window and switched themes back to Modern and in that new window only the Debug and QA menus open. Back in the first navigator window, none of the menus open anymore. Build 2001020904
*** Bug 68363 has been marked as a duplicate of this bug. ***
*** Bug 68492 has been marked as a duplicate of this bug. ***
I'm seeing this also with build 2001021008. For me at least the menus that won't open are any that had been opened before switching themes. Only the ones that hadn't been opened yet still work.
I'm seeing it on more than just the menus that I use before switching themes. But I haven't found a pattern yet.
I agree with Dean. After a View->Apply Theme command has been issued from the window, the window components that deal with navigation (Back, Forward, Reload and Stop), the throbber and the URLbar don't update when the current document is changed. But it's still possible to use them unless they were disabled before.
*** Bug 68610 has been marked as a duplicate of this bug. ***
*** Bug 68669 has been marked as a duplicate of this bug. ***
Whiteboard: critical for mozilla 0.8
I believe what Dean and Alex are referring to is a different issue covered by bug 68662. That issue is browser specific and I'm working on a fix. That said, I have no idea what's causing this bug.
*** Bug 68746 has been marked as a duplicate of this bug. ***
another confirm using win32 installer build 2001021408 m0.8 <gasp!> just adding my $0.02 by saying that opening a new browser window fixes the relevant menu problems.
*** Bug 68901 has been marked as a duplicate of this bug. ***
*** Bug 68906 has been marked as a duplicate of this bug. ***
Adding mostfreq keyword (9 dupes).
Keywords: mostfreq
Blocks: 68973
*** Bug 69026 has been marked as a duplicate of this bug. ***
*** Bug 69040 has been marked as a duplicate of this bug. ***
*** Bug 69050 has been marked as a duplicate of this bug. ***
*** Bug 69068 has been marked as a duplicate of this bug. ***
*** Bug 69090 has been marked as a duplicate of this bug. ***
*** Bug 68999 has been marked as a duplicate of this bug. ***
*** Bug 69321 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.8 → mozilla0.9
Target Milestone: mozilla0.8 → ---
moz0.8 is out. nominating for 0.9.
*** Bug 69535 has been marked as a duplicate of this bug. ***
*** Bug 69640 has been marked as a duplicate of this bug. ***
*** Bug 69777 has been marked as a duplicate of this bug. ***
I have messed a little bit with this, and here is the smallest testcase I could find: 1) In navigator.xul, in the main toolbar, I added <button class="button-toolbar-1 top" id="stop-button" crop="right" oncommand="hideMenubar();" value="Hide Menus"/> 2) In navigator.js, I added : function hideMenubar() { var menubar = document.getElementById('main-menubar'); (menubar.getAttribute("hidden") == "true") ? menubar.removeAttribute("hidden") : menubar.setAttribute("hidden", "true"); } This reproduces the bug everytime. I'm not sure however why, and also, why only some menus are affected!
*** Bug 69796 has been marked as a duplicate of this bug. ***
Marking dogfood. It's fun having to dup this bug 2x every day.
Keywords: dogfood
*** Bug 69958 has been marked as a duplicate of this bug. ***
*** Bug 70190 has been marked as a duplicate of this bug. ***
Is anyone working on this!? This is a big shame - someone with the knowledge and braveness must fix this for mozilla 0.9! I even think the Severity should be Critical.
Also, should this go to Skinability? I guess that's what's causing this bug. The menus are the side-effect - they are not the problem.
*** Bug 70479 has been marked as a duplicate of this bug. ***
As I mentioned in bug 70479, I was unable to reproduce this problem in either mozilla-0.7 or the 2001012310 nightly build, but it happened (with variations) in every build I tried from 2/8/01 onward. This bug was originally opened on the 2001020309 build; has anyone tested any builds between 1/23/01 and 2/3/01 for this bug to narrow down when it first appeared? Has anyone audited the code changes in this timeframe to look for this bug?
per hyatt, ->xpapps, please put try blocks around this, patch xul and js as needed.
Assignee: hyatt → ben
Status: REOPENED → NEW
Component: XP Toolkit/Widgets: Menus → XP Apps: GUI Features
Keywords: dogfood → nsdogfood
QA Contact: jrgm → sairuh
hyatt, put try blocks around what? I'm not really convinced this is an xpapps problem yet. Can you elaborate (with the knowledge that arbitrary menus are busted each time, null contentViewer or not)?
*** Bug 70659 has been marked as a duplicate of this bug. ***
The odd thing is that it only affects (or only seems to affect) menus which were opened before the switch, so I doubt it has anything to do with oncreate handlers. Also, Fabian's small testcase suggests you don't even need to skin switch. So, I just tested his testcase, and this is what happened: I opened a menu, closed it, and clicked the button (this hides the main menubar). I clicked the button to show the menubar again, tried to open the same menu, and couldn't. I could open another menu, but after clicking the button twice again, I also couldn't open that menu any longer. I tried a few combinations to see if this was something specific to only some menus, but it seems like the determining factor is whether the menu has been opened already or not.
Btw, I put this line in navigator.xul instead of Fabian's, right below the stop button: <button id="hide-button" crop="right" oncommand="hideMenubar();" value="Hide Menus"/>
*** Bug 70726 has been marked as a duplicate of this bug. ***
*** Bug 71017 has been marked as a duplicate of this bug. ***
Peter, after some experimentation, I concur that opening a menu before a theme switch will cause that menu to malfunction after the switch. However, it's NOT necessary to actually open the menu! Even highlighting the menu title with a simple mouseover is sufficient; you don't need to drop down the menu. What happens the first time the mouse moves over a menu that makes a difference?
This probably shouldn't be a surprise at this point, but opening a menu with an Alt-key shortcut is just as effective as a mouseover in causing that menu to malfunction after a theme switch.
Could a Javascript/XUL bug of some sort be causing this and bug 67442?
wfm in a build from today.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
interesting. also wfm on linux [2001.03.06.08]. marking verified. pls do reopen if it crops up again.
Status: RESOLVED → VERIFIED
I fixed this yesterday. It was my bug after all. :)
If you know what the bug was, could you explain the bug and fix, and mark this FIXED instead of WORKSFORME?
I don't know what you changed, but I concur that it is fixed in the current build (2001030608), and it was still broken in yesterday's build (2001030505). Too bad this didn't fix bug 67442 as well. :-)
hyatt: heh, thx. :)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
...and marking fixed per hyatt's comments.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
and vrfy!
Status: RESOLVED → VERIFIED
Any chance (again) that this fixed bug 51996 as well? Hyatt: Care to share where the fix took place?
Re: Bug 51996... nope. But now that this is fixed, who cares? (Well, I still do, but not nearly as much...)
Woohoo! :)
Not sure if there's a separate bug on this already, but even with the new build, after switching themes, the URLbar dropdown doesn't work anymore. The File, Edit, and View menus DO work, though.
Warner, I'd file that as a separate bug. All other menus, etc., seem to work fine after the switch, including the drop-downs on the back and forward buttons and auto-complete.
*** Bug 71265 has been marked as a duplicate of this bug. ***
*** Bug 71357 has been marked as a duplicate of this bug. ***
*** Bug 72909 has been marked as a duplicate of this bug. ***
The bug shows up again for Win32 build 2001050820. Cannot open View menu after switching theme.
I'm not seeing any problems with 050904 mozilla win32 build on win2K
doctor__j: Can you not open the menu at all, or does it just appear depressed? If it's the latter then that's probably bug 51996.
Well, the view menu item appeared depressed AND no View menu is drawn down. I can draw down File menu, Edit menu, and so on, except View menu.
This is working for me in 2001050904.
The View menu cannot be pulled down after switching themes. In addition, when other menu is pulled down (say Edit menu) and you sweep the mouse to go pass the View menu and then landed in other menus (say Bookmarks menu), the other menus are not pulled down any more as it was supposed to be. I can still see this bug on Win32 build 2001051504.
worksforme build 2001051308 win2k. The only wierd thing I'm seeing is that after switching skins and going back over the view menu, it appears "active" instead of "hover", but I can still open it without problem.
Doesn't work for me in build 2001060704 Error: this.docShell.contentViewer has no properties Source File: chrome://global/content/bindings/general.xml#browser.markupDocumentViewer (getter) Line: 0
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.

Attachment

General

Creator:
Created:
Updated:
Size: