DESCRIPTION: This problem seems to occur only in the first window that I open and not in subsequent windows. It is a regression that started in the past day or two. If I open a submenu on the personal toolbar, I see its contents doubled and as I mouse over the items in the upper part of the menu they are highlighted in the lower part of the menu. If I then click on one of the items (rather than closing the menu in some other way), the menu closes but the button that opened the menu stays focused (red color in classic skin, indented border) and steals all keyboard events until I click twice on the same button again or hit ESC. STEPS TO REPRODUCE: * create submenu on personal toolbar (is that sufficient? -- I"m not sure) * open it ACTUAL RESULTS: * menu doubling * when an item is selected, the new page doesn't have focus because the button on the toolbar that opens the menu still has focus I'm seeing this on my Linux opt build from this morning. :

Seeing this on 2001051220 on Windows 2000, changing OS to All

happens on my xlib solaris build (edit menu). platform: all.

This is due to stylesheet scoping.

*** Bug 80602 has been marked as a duplicate of this bug. ***

*** Bug 80679 has been marked as a duplicate of this bug. ***

Hyatt claims to have an idea what causes this

*** Bug 80736 has been marked as a duplicate of this bug. ***

The problem does not occur solely on the personal toolbar but also in the Back button menu, the newsgroup column menu, and others (as per bug 80736 which was marked as a duplicate).

*** Bug 80893 has been marked as a duplicate of this bug. ***

*** Bug 80935 has been marked as a duplicate of this bug. ***

This only seems to happen with one Personal Toolbar menu at a time, and sometimes switches to other menus in the toolbar. At least I'm seeing this on Win98SE 2001051420. New windows don't seem to be affected.

This bug also happens on: Edit menu (Alt+E), Go menu (Alt+G), Bookmarks menu (Alt+B), and Tasks menu (Alt+T), when the browser window is launched for the first time. Pressing the keyboard shortcuts will trigger this bug.

*** Bug 81151 has been marked as a duplicate of this bug. ***

*** Bug 81284 has been marked as a duplicate of this bug. ***

For those who are frustrated by this bug, a simple work around that always works for me is to open a new window and close the old one. New windows don't seem to be affected by this bug. Also, if Personal Toolbar folder looks depressed and is stealing focus away from your text fields, just hit Esc on your keyboard.

A more simple workaround is to open one of the main menu first.

Gilles: You mean one of the main menubar items, like File or Edit? Opening those doesn't work for me as a workaround for this.

*** Bug 80956 has been marked as a duplicate of this bug. ***

*** Bug 81343 has been marked as a duplicate of this bug. ***

This is pretty jarring, can we get a fix in for beta?

I think we should consider backing out stylesheet scoping for .9.1. Hyatt has already said he's too busy working on the style system rewrite to fix regressions like these, and I don't think the benefits of the landing outweigh the bugs it caused this close to the milestone.

On build 2001051621, using the main bookmarks menu first fixes the problem for the bookmarks menu on the personal toolbar. Using the personal toolbar menu first "sets" the problem. Whether this has any effects on the other personal toolbar menus I don't yet know.

The Lookup menu works after initially using the Bookmarks the main menu. Build 2001051621

Alex : clicking on file or edit does work as a workaround on my linux and win98 machine. Incidentally, while testing for this, I saw that just hovering on the main menu is a workaround on 2001051721 linux.

*** Bug 81609 has been marked as a duplicate of this bug. ***

We have 10 dups, adding mostfreq keyword. Gilles: yeah, your workaround does work. I keep going to the personal toolbar first before trying the main meubar.

*** Bug 81759 has been marked as a duplicate of this bug. ***

More information (for me, at least): if there are multiple personal toolbar folders, only the _first_ one I select shows this behavior. The first one will continue to show this as long as the window is open. All other folders work normally.

I don't think scoping should be backed out. This is probably pretty easy to fix, and it's the only known scoping bug.

hyatt, thanks for the update.

Er....it's the "only known scoping bug" now that about 7 other important ones have been fixed. And you said a few days ago that someone else better step up to fix these regressions, because you were busy. But whatever.

*** Bug 81875 has been marked as a duplicate of this bug. ***

On build 2001051821 (linux), moving the mouse on the main menu (without opening the menu) seems to be a sufficient workaround. So it isn't necessary to open a new window. The problem disapears as soon as I touch the main menu with the mouse. In fact, using the CTRL-N shortcut does not prevent the bug in the second window.

*** Bug 81252 has been marked as a duplicate of this bug. ***

*** Bug 82111 has been marked as a duplicate of this bug. ***

On linux, merely having the sidebar open on startup also works around this bug. It's amazing how quickly I have picked up the habit of visiting an almost-never-used Personal Toolbar bookmark menu to make sure that I don't get any of the bookmark menus I actually care about messed up. ;-)

Er, sorry, scratch that. I just tested the sidebar thing and it didn't make a difference. Guess I was confusing the workaround that Stephane Chauveau described with the sidebar issue.

*** Bug 82186 has been marked as a duplicate of this bug. ***

*** Bug 82292 has been marked as a duplicate of this bug. ***

*** Bug 81167 has been marked as a duplicate of this bug. ***

*** Bug 82550 has been marked as a duplicate of this bug. ***

*** Bug 82638 has been marked as a duplicate of this bug. ***

*** Bug 82681 has been marked as a duplicate of this bug. ***

*** Bug 82978 has been marked as a duplicate of this bug. ***

Blake, don't target my bugs for me.

Some of the drivers are using TM for tracking, and I was told to by one of them...

Since you added [helpwanted], could you share the idea mentioned above: | ------- Additional Comments From Joe Hewitt 2001-05-14 11:46 ------- | | Hyatt claims to have an idea what causes this

Can comfirm. It also seems that is not dependent on what is inside the folder, as, with out any changes to the contents of the bookmarks, it has shifted to a folder with 8 bookmarks in it, and no longer effects the origional with 4. Weird...

*** Bug 83073 has been marked as a duplicate of this bug. ***

*** Bug 83232 has been marked as a duplicate of this bug. ***

pchen may have a possible fix on this in similar bug http://bugzilla.mozilla.org/show_bug.cgi?id=78409.

Another workaround: right-clicking into the html-area (context-menu opens)

Another workaround: right-clicking into the html-area (context-menu opens)

*** Bug 83402 has been marked as a duplicate of this bug. ***

Is this bug going to be fixed for 0.9.1? If not, this bug, and it's various workarounds, needs to be mentioned in the release notes to save off a little bit of headache (I'll leave the 'relnote' keyword to whoever says that this won't make it into the 0.9.1). Although, fixing this for the milestone would be much nicer :)

*** Bug 81819 has been marked as a duplicate of this bug. ***

This is still critical for 0.9.1. hyatt, any reason you pushed it out?

Alec's way of opening an additional window of Mozilla works for my bug 81819 in a strange way. I open up Mozilla, open up a second window of Mozilla, and then close the second window, for my first window has it's bookmarks back !! Easier than my workaround, but still a little annoying :-((

*** Bug 83677 has been marked as a duplicate of this bug. ***

->moz0.9.1

This patch is tricky, so I'd like to shake it out on the 0.9.2 trunk before committing it to a 0.9.1 branch. Looking for r and sr. This patch does 2 things. First, it reverses the cascade order of scoped sheets to improve perf and decrease bloat. Second, it prevents a ContentAPpended notification from building frames when the parent has an insertion point with no frame. I changed the API for GetInsertionPoint on the frame manager, since I anticipate having to patch ContentInserted and ContentRemoved, and they'll need to pass in the content child being inserted or removed. I can patch those methods now if the person reviewing this decides I should. waterson, wanna do the sr? pink, r?

sr=waterson; careful, you've got random focus changes in your patch, too.

Ignore the patch to content. That patch is no good. I'm only looking for r/sr on the layout patch.

*** Bug 83768 has been marked as a duplicate of this bug. ***

*** Bug 83782 has been marked as a duplicate of this bug. ***

Someone give me an r and a, and I'll get this into 0.9.2 now.

r=blake on the stuff for this bug

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

*** Bug 83910 has been marked as a duplicate of this bug. ***

Fixed.

On Linux, this patch causes crash. Steps to reproduce: 1. Pull down any menu. 2. Press arrow key to choose menu item. 3. You'll see "Segmentation fault". I saw this problem on 2001060321-linux, on my own cvs build (apply layout patch over MOZ_CO_DATE = 06/01/2001 20:50:00 PDT).

This causes crash on windows too: 1) start typing in the URL field so that the outliner drops down with candidates for auto-completion (is there a snappy name for that?). 2) Alt-Tab to another app. 3) Alt-tab back to Mozilla Crash is in |GetInsertionPoint| in nsMenuBar.cpp, on the line aChild->GetContent(getter_AddRefs(child)); aChild is null because GetInsertionPoint was called like this from |GetNextMenuItem| GetInsertionPoint(shell, this, nsnull, &immediateParent);

Filed bug 83974 on the crasher. This bug did get fixed.

I still see this on Mac 2001-06-04-04 with a new profile

Let's use 83974 to track the crasher.

I think this slipped through the cracks. The original bug is in both trunk and branch builds(for mac at least) -create a new profile -launch app -click on tabs in the sidebar the customize menu is doubled reopening because the original bug still exists.

*** Bug 83974 has been marked as a duplicate of this bug. ***

sr=hewitt

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

Fixed (no, really!). :)

verified fixed in commercial builds windows 2001-06-05-06-trunk linux 2001-06-05-06-trunk mac 2001-06-05-04-trunk

um, why wasn't this fixed on the branch as well? it's pretty important that we get this fixed for beta. anybody?

I've tried applying the patches to my local trunk build minus the focus changes but it causes problems with the url grabbing the keyboard on linux when it shouldn't. I sent mail to hyatt asking for guidance about how this should be merged but I haven't heard anything back from him yet.

I am seeing this on mac branch build 2001-06-05-03-0.9.1 It didn't on branch for linux yesterday or today it was on branch fro windows yesterday should this be reopened or a branch bug opened?

It's definitely still on the branch.

Adding topcrash keyword and [@ GetInsertionPoint] [@nsMenuPopupFrame::GetNextMenuItem] to summary, since this crash has been reported under both of those stack signatures.

*** Bug 83801 has been marked as a duplicate of this bug. ***

Reopening so it will stay on the 0.9.1 radar.

Will this make it into the branch? Thanks for any update.

I don't have a Linux box for testing, so I'm hesitant to check this in to the branch if it's going to cause a major regression there. If someone wants to test on Linux, the correct patch to merge is the "Patch to layout DLL" minus the changes to nsPresShell.cpp, followed by the patch for ContentInserted. Do NOT apply the patch to the content DLL. That was a bad patch. Anyway I'm still feeling really sick, so I'm going home for the day. I could really use some help here from someone willing to test this on Linux and then check it in if it works ok.

The patch works fine for me in the trunk (tip). I don't have a branch build, so I can't check in for you, but it does work just fine for me.

I applied the patch (as noted above) to a fresh branch build (5pm pull), and with the patch applied, the "doubling" is fixed. I then spent 20 odd minutes in both skins, in composer, mail, browser, prefs, profilemanager, exercising various menus and popups, with no (unknown) problems noted. [Is there a particular "thing" that you can name that is at more risk than another].

Thank you, John. I wonder if we would feel comfortable now to take this on the branch since the John has completed the testing which Dave Hyatt was inquiring about. This change has gotten some "bake" time on the trunk already for Win32 and Mac.

What about blizzard's comment of 2001-06-05 11:17? Is this really ready to go?

I'm not exactly sure what Chris meant by "the url grabbing the keyboard". blizzard?

When I applied the patches several days ago just as hyatt has just described here I had problems with the autocomplete window / url bar grabbing the keyboard even though the autocomplete window wasn't visible. I can go back and try it again. Maybe it was something else in my build. I doubt that it was but I'll give it a go anyway.

I've re-applied the patches and I'm not seeing any of the bad effects that I was seeing before so I think we're OK.

Attached is a patch for 0.9.1 that doesn't include the preshell.cpp changes and includes the ContentInserted patch.

This is in the 0.9.1 branch now.

This looks good using 0.9.1 2001060712/Linux.

--> fixed. Thanks blizzard!

Fix looks good from what I see in mail/news windows with: 2001-06-07-13-0.9.1 commercial branch win98 2001-06-07-11-0.9.1 commercial branch mac OS 9.0

Mail windows also look okay with commercial branch 2001-06-07-13-0.9.1 on linux rh6.2. I've asked others in the mailnews QA group to keep an eye out and comment here if they see the problem in the branch builds.

i don't encounter this using 2001.06.07.13-branch comm bits on winnt.

verified on 06/07 linux/mac/win32 branch comm. builds