The default bug view has changed. See this FAQ.

Can't open (some) menus after switching themes

VERIFIED FIXED

Status

SeaMonkey
UI Design
--
major
VERIFIED FIXED
16 years ago
3 years ago

People

(Reporter: Mark Bialkowski, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({regression})

Trunk
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

16 years ago
Confirming for 2001/02/02/20 build on Win2k. Platform and OS should be ALL.

Comment 2

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

Comment 3

16 years ago
*** Bug 67660 has been marked as a duplicate of this bug. ***

Comment 4

16 years ago
*** Bug 67660 has been marked as a duplicate of this bug. ***

Comment 5

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

Comment 6

16 years ago
this is ugly and highly visible.  would be great to see this fixed for 0.8
Whiteboard: critical for mozilla 0.8

Comment 7

16 years ago
I know how to fix this.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8

Comment 8

16 years ago
sr=brendan@mozilla.org (brendan using hyatt's iMac).

/be

Comment 9

16 years ago
Created attachment 24684 [details] [diff] [review]
Fix.

Comment 10

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

Comment 12

16 years ago
Any chance this fixes bug 51996?

Comment 13

16 years ago
*** Bug 68077 has been marked as a duplicate of this bug. ***

Comment 14

16 years ago
fixed.

Comment 15

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 16

16 years ago
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 → ---

Comment 17

16 years ago
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).

Comment 18

16 years ago
Sorry....

Nevermind about it being confined to Edit.  I just saw it for almost every menu 
in Editor.

Comment 19

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

Comment 20

16 years ago
*** Bug 68363 has been marked as a duplicate of this bug. ***

Comment 21

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

Comment 23

16 years ago
I'm seeing it on more than just the menus that I use before switching themes.  
But I haven't found a pattern yet.

Comment 24

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

Comment 25

16 years ago
*** Bug 68610 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
*** Bug 68669 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Whiteboard: critical for mozilla 0.8

Comment 27

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

Comment 28

16 years ago
*** Bug 68746 has been marked as a duplicate of this bug. ***

Comment 29

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

Comment 30

16 years ago
*** Bug 68901 has been marked as a duplicate of this bug. ***

Comment 31

16 years ago
*** Bug 68906 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
Adding mostfreq keyword (9 dupes).
Keywords: mostfreq

Updated

16 years ago
Blocks: 68973

Comment 33

16 years ago
*** Bug 69026 has been marked as a duplicate of this bug. ***

Comment 34

16 years ago
*** Bug 69040 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
*** Bug 69050 has been marked as a duplicate of this bug. ***

Comment 36

16 years ago
*** Bug 69068 has been marked as a duplicate of this bug. ***

Comment 37

16 years ago
*** Bug 69090 has been marked as a duplicate of this bug. ***
*** Bug 68999 has been marked as a duplicate of this bug. ***

Comment 39

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

Comment 41

16 years ago
*** Bug 69535 has been marked as a duplicate of this bug. ***

Comment 42

16 years ago
*** Bug 69640 has been marked as a duplicate of this bug. ***

Comment 43

16 years ago
*** Bug 69777 has been marked as a duplicate of this bug. ***

Comment 44

16 years ago
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!

Comment 45

16 years ago
*** Bug 69796 has been marked as a duplicate of this bug. ***

Comment 46

16 years ago
Marking dogfood.  It's fun having to dup this bug 2x every day.
Keywords: dogfood

Comment 47

16 years ago
*** Bug 69958 has been marked as a duplicate of this bug. ***

Comment 48

16 years ago
*** Bug 70190 has been marked as a duplicate of this bug. ***

Comment 49

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

Comment 50

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

Comment 52

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

Comment 53

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

Comment 54

16 years ago
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)?

Comment 55

16 years ago
*** Bug 70659 has been marked as a duplicate of this bug. ***

Comment 56

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

Comment 57

16 years ago
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"/>

Comment 58

16 years ago
*** Bug 70726 has been marked as a duplicate of this bug. ***

Comment 59

16 years ago
*** Bug 71017 has been marked as a duplicate of this bug. ***

Comment 60

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

Comment 61

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

Comment 62

16 years ago
Could a Javascript/XUL bug of some sort be causing this and bug 67442?

Comment 63

16 years ago
wfm in a build from today.
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 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

Comment 65

16 years ago
I fixed this yesterday.  It was my bug after all.  :)

Comment 66

16 years ago
If you know what the bug was, could you explain the bug and fix, and mark this
FIXED instead of WORKSFORME?

Comment 67

16 years ago
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
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
and vrfy!
Status: RESOLVED → VERIFIED

Comment 71

16 years ago
Any chance (again) that this fixed bug 51996 as well?

Hyatt: Care to share where the fix took place?

Comment 72

16 years ago
Re: Bug 51996... nope.  But now that this is fixed, who cares?  (Well, I still
do, but not nearly as much...)

Comment 73

16 years ago
Woohoo! :)

Comment 74

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

Comment 75

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

Comment 76

16 years ago
*** Bug 71265 has been marked as a duplicate of this bug. ***

Comment 77

16 years ago
*** Bug 71357 has been marked as a duplicate of this bug. ***

Comment 78

16 years ago
*** Bug 72909 has been marked as a duplicate of this bug. ***

Comment 79

16 years ago
The bug shows up again for Win32 build 2001050820.

Cannot open View menu after switching theme.

Comment 80

16 years ago
I'm not seeing any problems with 050904 mozilla win32 build on win2K

Comment 81

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

Comment 82

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

Comment 83

16 years ago
This is working for me in 2001050904.

Comment 84

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

Comment 85

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

Comment 86

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

Updated

9 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.