[Rod Spears wrote, and probably tested on NT, the following:] When I load the browser the events are not delivered to the correct frame. When I use the -editor flag and it loads EditorAppShell.xul the events go to the correct from. So as an experiment I used the "-url" option and loaded EditorAppShell.xul in the apprunner (this doesn't turn on editing) the event target is fine. There is something broken in the navigator.xul file that makes events get processed incorrectly. It's easy to test, the toolbar frame gets mouse events when EditorAppShell.xul is loaded and does not when navigator.xul is loaded. The strange thing is the nsWindow receiving the events in editor mode has an installed event handler the is nsView::HandleEvent, when its the navigator.xul it goes to nsWebShellWindow::HandleEvent.

Thanks Chris. When I saw your post in the newsgroup, somehow I knew you had assigned this to me! I'm going to pass it off to hyatt, since Rod was already stumped by it.

This involves a re-architecting of the toolbars to have <toolbaritem> nodes. Can wait until drag and drop on toolbars. M7.

Reassigning to pink.

yikes, this ain't getting fixed by M7. Peter? help?

rod, per our discussion last week, i'm passing this off to you, and moving it to M10 as per the schedule. Is that cool? adding myself to cc list as well.

This work is now checked in.

this is what i did: 1. run apprunner with the args '-url chrome://editor/content/EditorAppShell.xul' ( mouseover works fine on buttons and the content does not change ) 2. now use '-url chrome://navigator/content/navigator.xul' ( mouseover works fine on the buttons, but mozillazine replaces the apparently embedded apprunner within about a second. ) in both cases, the xul content correctly receives mouse events. im marking this verified. reopen if i'm wrong here... tested on 1999-07-26-14 RedHat Linux 5.2 (GNOME/enlightenment) 1999-07-26-08 WinNT 4.0 sp4 1999-07-26-08 MacOS 8.51